[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
"Michael S. Tsirkin" <mst@redhat.com> writes:
> 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.
Just to make sure I understand correctly, with this information:
1) Attempting to provide a mechanism for reprogramming the MTU using
the driver/device is a no-go for some operating systems'
incompatibility
2) We could provide a maximum initial value, and the guest is free, on
initialization to pick a smaller initial value
If this is good enough, I can rework the patches ONLY to state these
things, and we can leave reprogramming the MTU as a work for guest
agent, or some future mechanism.
Did I understand this? Does the approach seem correct?
>>
>>
>>
>>
>>
>>
>> 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
>>
>>
>
> ---------------------------------------------------------------------
> 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]