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: [PATCH v8] virtio-net: add Max MTU configuration field

It is helpful for a host to indicate an advisory MTU value to be set
on guest's NICs other than the assumed 1500 byte value.  This helps in
situations where the host network is using Jumbo Frames, or aiding in
PMTU discovery by configuring a homogenous network.

The change adds a new field to configuration area of network
devices.  It will be used to pass a maximum MTU from the device to
the driver.  This will be used by the driver as a maximum value for
packet sizes during transmission, without segmentation offloading.

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

Signed-off-by: Aaron Conole <aconole@redhat.com>
Cc: Victor Kaplansky <victork@redhat.com>
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
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 host->guest
communication through a driver read-only and driver write-only field.

Converted to just support initial MTU. Guest->host and Host->guest MTU
changes are outside the scope of this change.

Removed references to 'initial', since that condition cannot be tested.
Simply state that if the driver will use the mtu field, it must
negotiate the feature bit, and if not, it must not.

After feedback from Michael S. Tsirkin

Bit has to change to bit 25 due to an undocumented bit 24 being taken.

Partial rewrite with feedback from MST.  Additional conformance statements

Clarified the new conformance statements.

Previous series:

 Note: should this proposal be accepted and approved, one or more
       claims disclosed to the TC admin and listed on the Virtio TC
       IPR page https://www.oasis-open.org/committees/virtio/ipr.php
       might become Essential Claims.

 content.tex | 34 ++++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/content.tex b/content.tex
index 4b45678..b90cbad 100644
--- a/content.tex
+++ b/content.tex
@@ -3049,6 +3049,14 @@ features.
 \item[VIRTIO_NET_F_CTRL_GUEST_OFFLOADS (2)] Control channel offloads
         reconfiguration support.
+\item[VIRTIO_NET_F_MTU(3)] Maximum negotiated MTU is supported. If
+    offered by the device, device advises driver about the value of
+    MTU to be used. If negotiated, the driver uses \field{mtu} as
+    the maximum MTU value supplied to the operating system.
+    Note: many operating systems override the MTU value provided by the
+    driver.
 \item[VIRTIO_NET_F_MAC (5)] Device has given MAC address.
 \item[VIRTIO_NET_F_GUEST_TSO4 (7)] Driver can receive TSOv4.
@@ -3140,11 +3148,16 @@ 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 maximum MTU for the driver to
 struct virtio_net_config {
         u8 mac[6];
         le16 status;
         le16 max_virtqueue_pairs;
+        le16 mtu;
@@ -3153,6 +3166,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.
+The device MUST set \field{mtu} to between 68 and 65535 inclusive,
+if it offers VIRTIO_NET_F_MTU.
+The device MUST NOT modify \field{mtu} once it has been set.
+The device MUST NOT pass received packets that exceed \field{mtu} size
+with \field{gso_type} NONE or ECN if it offers VIRTIO_NET_F_MTU.
+The device MUST forward transmitted packets of up to MTU size with
+\field{gso_type} NONE or ECN, and do so without fragmentation, if it
 \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.
@@ -3165,6 +3190,15 @@ 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}.
+If the device offers VIRTIO_NET_F_MTU, a driver MUST supply enough receive
+buffers of size \field{mtu} to be able to receive at least one receive
+packet with \field{gso_type} NONE or ECN.
+A driver SHOULD negotiate VIRTIO_NET_F_MTU if the device offers it.
+If the device offers VIRTIO_NET_F_MTU, a driver MUST NOT transmit packets of
+size exceeding the value of \field{mtu} with \field{gso_type} NONE or ECN
 \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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]