Re: [virtio-dev] Re: [PATCH v2] virtio-net: add mtu configuration field

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Jan 20, 2016 at 12:42:45PM -0500, Aaron Conole wrote:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
> > On Fri, Jan 15, 2016 at 04:28:30PM -0500, Aaron Conole wrote:
> >> Sometimes it is essential for libvirt to be able to configure MTU
> >> on guest's NICs to a value different from 1500.
> >> 
> >> The change adds a new field to configuration area of network
> >> devices. It will be used to pass initial MTU from the device to
> >> the driver, and to pass modified MTU from driver to the device
> >> or from device to driver for both host-guest and guest-host
> >> interaction.
> >> 
> >> In addition, in order to support backward and forward
> >> compatibility, we introduce a new feature bit called
> >> VIRTIO_NET_F_DEFAULT_MTU.
> >> 
> >> Signed-off-by: Aaron Conole <aconole@redhat.com>
> >> Cc: Victor Kaplansky <victork@redhat.com>
> >
> > Since apparently windows guests can't support
> > such mtu negotiation in the driver, we'd have
> > to implement this in a guest agent for these
> > guests.
> 
> I think that was due to a previous patch which did not include a
> mechanism for reporting the guest->host changes. This includes such a
> feedback mechanism. However, I may have misunderstood Yan's previous
> email.
> 

This part?
	We don’t have the way to support host report of MTU change to the guest
	on Windows.

Actually I have a question about this, too.

MTU changes can't be reported to guest, ok.

But let's assume MTU is static.
Can this MTU be discovered during install?

I see this:

NetKVM/wlh/ParaNdis6-Driver.c:
miniportAttributes.GeneralAttributes.MtuSize =
pContext->MaxPacketSize.nMaxDataSize;

Yan?


> Please advise, Yan.
>
> > It thus seems advantageous to always have it in
> > a guest agent, so that libvirt can change it
> > for all guests in the same way, consistently.
> >
> > Do you agree to the above? If yes, why do we need
> > a new device field?
> 
> I am not very familiar with qemu-ga. If Yan says the new proposal
> will not work, then I will investigate that more thoroughly.
> 
> >> ---
> >> 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.
> >> 
> >>  content.tex | 31 +++++++++++++++++++++++++++++++
> >>  1 file changed, 31 insertions(+)
> >> 
> >> diff --git a/content.tex b/content.tex
> >> index d989d98..b855691 100644
> >> --- a/content.tex
> >> +++ b/content.tex
> >> @@ -3078,6 +3078,11 @@ features.
> >>  
> >>  \item[VIRTIO_NET_F_CTRL_MAC_ADDR(23)] Set MAC address through control
> >>      channel.
> >> +
> >> +\item[VIRTIO_NET_F_MTU(24)] Negotiated MTU is supported. If
> >> +    offered by the device, device advises driver about initial
> >> +    MTU to be used. If negotiated, the driver uses \field{mtu} as
> >> +    an initial value.
> >>  \end{description}
> >>  
> >>  \subsubsection{Feature bit requirements}\label{sec:Device Types / Network Device / Feature bits / Feature bit requirements}
> >> @@ -3132,11 +3137,21 @@ 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 MTU that the device expects
> >> +the driver to honor.
> >> +
> >> +The following driver-write-only field, \field{mtu_requested} only exists if
> >> +VIRTIO_NET_F_MTU is set. This field will be written by the driver when it wants
> >> +to request an MTU change from the device.
> >> +
> >>  \begin{lstlisting}
> >>  struct virtio_net_config {
> >>          u8 mac[6];
> >>          le16 status;
> >>          le16 max_virtqueue_pairs;
> >> +        le16 mtu;
> >> +        le16 mtu_requested;
> >>  };
> >>  \end{lstlisting}
> >>  
> >> @@ -3145,6 +3160,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.
> >>  
> >> +\devicenormative{\subsubsection}{Device configuration layout}{Device Types / Network Device / Device configuration layout}
> >> +
> >> +The device MUST set \field{mtu} to between 68 and 65535 inclusive,
> >> +if it offers VIRTIO_NET_F_MTU.
> >> +
> >> +Any time the device modifies \field{mtu}, it MUST send a configuration change
> >> +notification.
> >> +
> >> +The driver MAY set \field{mtu_requested} to between 68 and 65535 inclusive,
> >> +if the device offers VIRTIO_NET_F_MTU. Any time the driver modifies
> >> +\field{mtu_requested}, it MUST also send a configuration change notification.
> >> +
> >>  \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.
> >> @@ -3157,6 +3184,10 @@ 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 the VIRTIO_NET_F_MTU feature, the driver MUST use \field{mtu}
> >> +as the value for MTU.
> >> +
> >>  \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.5.0
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org