[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]