On Tue, Sep 13, 2016 at 11:18:12AM -0400, Aaron Conole wrote: > It is helpful for a host to indicate it's MTU to be set on guest NICs > other than the assumed 1500 byte value. This helps in situations where > the host network is using Jumbo Frames, or aiding in PMTU discovery by > configuring a homogenous network. It is also helpful for sizing receive > buffers correctly. > > The change adds a new field to configuration area of network > devices. It will be used to pass a maximum MTU from the device to > the driver. This will be used by the driver as a maximum value for > packet sizes during transmission, without segmentation offloading. > > In addition, in order to support backward and forward compatibility, > we introduce a new feature bit called VIRTIO_NET_F_MTU. > > VIRTIO-152 > Signed-off-by: Aaron Conole <aconole@xxxxxxxxxx> > Cc: Victor Kaplansky <victork@xxxxxxxxxx> > Acked-by: Michael S. Tsirkin <mst@xxxxxxxxxx> > Acked-by: Maxime Coquelin <maxime.coquelin@xxxxxxxxxx> Cornelia, could you pls ack before I start voting? > --- > v1: > This is an attempt at continuing the work done by Victor Kaplansky on > mtu negiotiation for virtio-net devices. It attempts to pick up from > https://lists.oasis-open.org/archives/virtio-dev/201508/msg00007.html > and is just a minor blurb from the first patch along with the 2nd patch > from the series, and some of the feedback integrated. > > v2: > Rephrase and provide a mechanism for guest->host and host->guest > communication through a driver read-only and driver write-only field. > > v3: > Converted to just support initial MTU. Guest->host and Host->guest MTU > changes are outside the scope of this change. > > v4: > Removed references to 'initial', since that condition cannot be tested. > Simply state that if the driver will use the mtu field, it must > negotiate the feature bit, and if not, it must not. > > v5: > After feedback from Michael S. Tsirkin > > v6: > Bit has to change to bit 25 due to an undocumented bit 24 being taken. > > v7: > Partial rewrite with feedback from MST. Additional conformance statements > added. > > v8: > Clarified the new conformance statements. > > v9: > Updated the commit log for correctness. Added ACKs from > Michael S. Tsirkin, and Maxime Coquelin. Included the virtio > issue id. > > v10: > Update the conformance statement wordings from previous 'offered' form > to 'succesfully negotiated' form. > > content.tex | 32 ++++++++++++++++++++++++++++++++ > 1 file changed, 32 insertions(+) > > diff --git a/content.tex b/content.tex > index 4b45678..42c0568 100644 > --- a/content.tex > +++ b/content.tex > @@ -3049,6 +3049,11 @@ features. > \item[VIRTIO_NET_F_CTRL_GUEST_OFFLOADS (2)] Control channel offloads > reconfiguration support. > > +\item[VIRTIO_NET_F_MTU(3)] Maximum negotiated MTU is supported. If > + offered by the device, device advises driver about the value of > + MTU to be used. If negotiated, the driver uses \field{mtu} as > + the maximum MTU value supplied to the driver. > + > \item[VIRTIO_NET_F_MAC (5)] Device has given MAC address. > > \item[VIRTIO_NET_F_GUEST_TSO4 (7)] Driver can receive TSOv4. > @@ -3140,11 +3145,16 @@ of each of transmit and receive virtqueues (receiveq1\ldots receiveqN > and transmitq1\ldots transmitqN respectively) that can be configured once VIRTIO_NET_F_MQ > is negotiated. > > +The following driver-read-only field, \field{mtu} only exists if > +VIRTIO_NET_F_MTU is set. This field specifies the maximum MTU for the driver to > +use. > + > \begin{lstlisting} > struct virtio_net_config { > u8 mac[6]; > le16 status; > le16 max_virtqueue_pairs; > + le16 mtu; > }; > \end{lstlisting} > > @@ -3153,6 +3163,19 @@ struct virtio_net_config { > The device MUST set \field{max_virtqueue_pairs} to between 1 and 0x8000 inclusive, > if it offers VIRTIO_NET_F_MQ. > > +The device MUST set \field{mtu} to between 68 and 65535 inclusive, > +if it offers VIRTIO_NET_F_MTU. > + > +The device MUST NOT modify \field{mtu} once it has been set. > + > +The device MUST NOT pass received packets that exceed \field{mtu} size > +with \field{gso_type} NONE or ECN after VIRTIO_NET_F_MTU has been successfully > +negotiated. > + > +The device MUST forward transmitted packets of up to MTU size with > +\field{gso_type} NONE or ECN, and do so without fragmentation, after > +VIRTIO_NET_F_MTU has been successfully negotiated. > + > \drivernormative{\subsubsection}{Device configuration layout}{Device Types / Network Device / Device configuration layout} > > A driver SHOULD negotiate VIRTIO_NET_F_MAC if the device offers it. > @@ -3165,6 +3188,15 @@ If the driver does not negotiate the VIRTIO_NET_F_STATUS feature, it SHOULD > assume the link is active, otherwise it SHOULD read the link status from > the bottom bit of \field{status}. > > +A driver SHOULD negotiate VIRTIO_NET_F_MTU if the device offers it. > + > +If the driver negotiates VIRTIO_NET_F_MTU, it MUST supply enough receive > +buffers of size \field{mtu} to be able to receive at least one receive > +packet with \field{gso_type} NONE or ECN. > + > +If the driver negotiates VIRTIO_NET_F_MTU, it MUST NOT transmit packets of > +size exceeding the value of \field{mtu} with \field{gso_type} NONE or ECN > + > \subsubsection{Legacy Interface: Device configuration layout}\label{sec:Device Types / Network Device / Device configuration layout / Legacy Interface: Device configuration layout} > \label{sec:Device Types / Block Device / Feature bits / Device configuration layout / Legacy Interface: Device configuration layout} > When using the legacy interface, transitional devices and drivers > -- > 2.7.4 _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
