OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio-dev] [PATCH v8] virtio-net: add Max MTU configuration field


"Michael S. Tsirkin" <mst@redhat.com> writes:

> 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 <aconole@redhat.com>
>> > Cc: Victor Kaplansky <victork@redhat.com>
>> 
>> Acked-by: Michael S. Tsirkin <mst@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.
>

Thanks so much for the feedback, Michael.  I have applied the changes
you requested, and added your ACK.

-Aaron

>> > ---
>> > 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-unsubscribe@lists.oasis-open.org
>> > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]