On Sun, Sep 04, 2016 at 08:50:57PM +0300, Michael S. Tsirkin wrote: > On Sun, Sep 04, 2016 at 10:31:09AM -0400, Aaron Conole wrote: > > It is helpful for a host to indicate an advisory MTU value to be set > > on guest's NICs other than the assumed 1500 byte value. > > This part of the description is wrong now. > It is no longer advisory and it should say "to indicate its MTU value". > > > This helps in > > situations where the host network is using Jumbo Frames, or aiding in > > PMTU discovery by configuring a homogenous network. > > Maybe add > ... 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. > > > > Signed-off-by: Aaron Conole <acon...@redhat.com> > > Cc: Victor Kaplansky <vict...@redhat.com> > > Acked-by: Michael S. Tsirkin <m...@redhat.com> >
I created an issue to track this. Pls post with a fixed commit log and add VIRTIO-152 on a line by itself in the log. > > --- > > 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. > > > > Previous series: > > https://lists.oasis-open.org/archives/virtio-dev/201608/msg00056.html > > > > Note: should this proposal be accepted and approved, one or more > > claims disclosed to the TC admin and listed on the Virtio TC > > IPR page https://www.oasis-open.org/committees/virtio/ipr.php > > might become Essential Claims. > > > > > > content.tex | 34 ++++++++++++++++++++++++++++++++++ > > 1 file changed, 34 insertions(+) > > > > diff --git a/content.tex b/content.tex > > index 4b45678..b90cbad 100644 > > --- a/content.tex > > +++ b/content.tex > > @@ -3049,6 +3049,14 @@ 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 operating system. > > + > > + Note: many operating systems override the MTU value provided by 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 +3148,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 +3166,18 @@ 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 if it offers VIRTIO_NET_F_MTU. > > + > > +The device MUST forward transmitted packets of up to MTU size with > > +\field{gso_type} NONE or ECN, and do so without fragmentation, if it > > +offers VIRTIO_NET_F_MTU. > > + > > \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 +3190,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}. > > > > +If the device offers VIRTIO_NET_F_MTU, a driver 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. > > + > > +A driver SHOULD negotiate VIRTIO_NET_F_MTU if the device offers it. > > + > > +If the device offers VIRTIO_NET_F_MTU, a driver 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 > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org > > For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org