[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] Re: [PATCH v2] virtio-net: add mtu configuration field
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]