OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[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 25 Jan 2016, at 17:03, Aaron Conole <aconole@redhat.com> wrote:

"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

                      Sometimes it is essential for libvirt to be able to
                      on guest's NICs to a value different from 1500.

                      The change adds a new field to configuration area of
                      devices. It will be used to pass initial MTU from the
       device to
                      the driver, and to pass modified MTU from driver to the
                      or from device to driver for both host-guest and

                      In addition, in order to support backward and forward
                      compatibility, we introduce a new feature bit called

                      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

              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

       What I meant to say is that in Windows we cannot dynamically change MTU
       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
          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

   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'

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?

OK from my side for this kind of approach. 

          I see this:

          miniportAttributes.GeneralAttributes.MtuSize =

       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->
       = pConfiguration->MTU.ulValue;


              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
              will not work, then I will investigate that more thoroughly.

                      This is an attempt at continuing the work done by Victor
                      Kaplansky on
                      mtu negiotiation for virtio-net devices. It attempts to
       pick up
                      and is just a minor blurb from the first patch along
       with the
                      2nd patch
                      from the series, and some of the feedback integrated.

                      Rephrase and provide a mechanism for guest->host and
                      communication through a driver read-only and driver

                      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
                      +\item[VIRTIO_NET_F_MTU(24)] Negotiated MTU is
       supported. If
                      +    offered by the device, device advises driver about
                      +    MTU to be used. If negotiated, the driver uses \
                      +    an initial value.

                      \subsubsection{Feature bit requirements}\label
       {sec:Device Types
                      / Network Device / Feature bits / Feature bit
                      @@ -3132,11 +3137,21 @@ of each of transmit and receive
                      virtqueues (receiveq1\ldots receiveqN
                      and transmitq1\ldots transmitqN respectively) that can
                      configured once VIRTIO_NET_F_MQ
                      is negotiated.

                      +The following driver-read-only field, \field{mtu} only
                      +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
                      only exists if
                      +VIRTIO_NET_F_MTU is set. This field will be written by
                      driver when it wants
                      +to request an MTU change from the device.
                      struct virtio_net_config {
                              u8 mac[6];
                              le16 status;
                              le16 max_virtqueue_pairs;
                      +        le16 mtu;
                      +        le16 mtu_requested;

                      @@ -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
                      {Device Types / Network Device / Device configuration
                      +The device MUST set \field{mtu} to between 68 and 65535
                      +if it offers VIRTIO_NET_F_MTU.
                      +Any time the device modifies \field{mtu}, it MUST send
                      configuration change
                      +The driver MAY set \field{mtu_requested} to between 68
                      65535 inclusive,
                      +if the device offers VIRTIO_NET_F_MTU. Any time the
                      +\field{mtu_requested}, it MUST also send a
                      change notification.
                      \drivernormative{\subsubsection}{Device configuration
                      {Device Types / Network Device / Device configuration

                      A driver SHOULD negotiate VIRTIO_NET_F_MAC if the device
                      @@ -3157,6 +3184,10 @@ If the driver does not negotiate
                      VIRTIO_NET_F_STATUS feature, it SHOULD
                      assume the link is active, otherwise it SHOULD read the
                      status from
                      the bottom bit of \field{status}.

                      +A driver SHOULD negotiate VIRTIO_NET_F_MTU if the
                      offers it.  If the
                      +driver negotiates the VIRTIO_NET_F_MTU feature, the
                      MUST use \field{mtu}
                      +as the value for MTU.
                      \subsubsection{Legacy Interface: Device configuration
                      label{sec:Device Types / Network Device / Device
                      layout / Legacy Interface: Device configuration layout}
                      \label{sec:Device Types / Block Device / Feature bits /
                      configuration layout / Legacy Interface: Device
                      When using the legacy interface, transitional devices

                  To unsubscribe, e-mail:
                  For additional commands, e-mail:

   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]