[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] [PATCH v2] virtio-net: add mtu configuration field
On Mon, Jan 25, 2016 at 10:32:29AM +0200, Yan Vugenfirer wrote: > > On 24 Jan 2016, at 11:27, Michael S. Tsirkin <mst@redhat.com> wrote: > > On Sun, Jan 24, 2016 at 10:42:24AM +0200, Yan Vugenfirer wrote: > > > On 21 Jan 2016, at 07:27, Michael S. Tsirkin <mst@redhat.com> wrote: > > 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. > > > > What I meant to say is that in Windows we cannot dynamically change MTU > from > the device driver. We can set MTU on driver initialisation. Also > > > > 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? > > > If it is static, it can be discovered during driver load with some > restrictions. > > > Are the restrictions on value or on how it's accessed then? > > > By restriction I meant that the driver is not fully initialised yet. So we will > have to use control queue in poll mode. > Initial value restrictions are in the registry, but I think we can ignore them > in this case. Or use the min value between the two. > > > > > > > I see this: > > NetKVM/wlh/ParaNdis6-Driver.c: > miniportAttributes.GeneralAttributes.MtuSize = > pContext->MaxPacketSize.nMaxDataSize; > > > > This is an initialisation of the miniport driver. We could access > virtio device > at this point (most probably without interrupts) and get MTU. > Currently we get the value from registry - pContext-> > MaxPacketSize.nMaxDataSize > = pConfiguration->MTU.ulValue; > > > > 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 > > > > > --------------------------------------------------------------------- > 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]