[virtio-dev] [PATCH v11] virtio-net: add Max MTU configuration field
It is helpful for a host to indicate it's MTU to be set on guest 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. It is also helpful for sizing receive
buffers correctly.
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.
VIRTIO-152
Signed-off-by: Aaron Conole <acon...@redhat.com>
Cc: Victor Kaplansky <vict...@redhat.com>
Reviewed-by: Hannes Reiencke <h...@suse.de>
Acked-by: Michael S. Tsirkin <m...@redhat.com>
Acked-by: Maxime Coquelin <maxime.coque...@redhat.com>
---
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.
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/msg7.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.
v3:
Converted to just support initial MTU. Guest->host and Host->guest MTU
changes are outside the scope of this change.
v4:
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.
v5:
After feedback from Michael S. Tsirkin
v6:
Bit has to change to bit 25 due to an undocumented bit 24 being taken.
v7:
Partial rewrite with feedback from MST. Additional conformance statements
added.
v8:
Clarified the new conformance statements.
v9:
Updated the commit log for correctness. Added ACKs from
Michael S. Tsirkin, and Maxime Coquelin. Included the virtio
issue id.
v10:
Update the conformance statement wordings from previous 'offered' form
to 'succesfully negotiated' form.
v11:
Clarified size w.r.t. MTU - buffer sizes must also add extra space for ethernet
headers. Also updated the feature bit description.
content.tex | 37 +
1 file changed, 37 insertions(+)
diff --git a/content.tex b/content.tex
index 4b45678..45b94c6 100644
--- a/content.tex
+++ b/content.tex
@@ -3049,6 +3049,11 @@ features.
\item[VIRTIO_NET_F_CTRL_GUEST_OFFLOADS (2)] Control channel offloads
reconfiguration support.
+\item[VIRTIO_NET_F_MTU(3)] Device maximum MTU reporting is supported. If
+offered by the device, device advises driver about the value of
+its maximum MTU. If negotiated, the driver uses \field{mtu} as
+the maximum MTU value.
+
\item[VIRTIO_NET_F_MAC (5)] Device has given MAC address.
\item[VIRTIO_NET_F_GUEST_TSO4 (7)] Driver can receive TSOv4.
@@ -3140,11 +3145,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
+use.
+
\begin{lstlisting}
struct virtio_net_config {
u8 mac[6];
le16 status;
le16 max_virtqueue_pairs;
+le16 mtu;
};
\end{lstlisting}
@@ -3153,6 +3163,23 @@ 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 SHOULD set \field{mtu} to at least 1280, 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} (plus low
+level ethernet header length) size with \field{gso_type} NONE or ECN
+after VIRTIO_NET_F_MTU has been successfully negotiated.
+
+The device MUST forward transmitted packets of up to \field{mtu} (plus low
+level ethernet header length) size with \field{gso_type} NONE or ECN, and do
+so without fragmentation, after VIRTIO_NET_F_MTU has been successfully
+negotiated.
+
\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 +3192,16 @@ If the driver does not
[virtio-dev] [PATCH v10] virtio-net: add Max MTU configuration field
It is helpful for a host to indicate it's MTU to be set on guest 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. It is also helpful for sizing receive
buffers correctly.
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.
VIRTIO-152
Signed-off-by: Aaron Conole <acon...@redhat.com>
Cc: Victor Kaplansky <vict...@redhat.com>
Acked-by: Michael S. Tsirkin <m...@redhat.com>
Acked-by: Maxime Coquelin <maxime.coque...@redhat.com>
---
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/msg7.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.
v3:
Converted to just support initial MTU. Guest->host and Host->guest MTU
changes are outside the scope of this change.
v4:
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.
v5:
After feedback from Michael S. Tsirkin
v6:
Bit has to change to bit 25 due to an undocumented bit 24 being taken.
v7:
Partial rewrite with feedback from MST. Additional conformance statements
added.
v8:
Clarified the new conformance statements.
v9:
Updated the commit log for correctness. Added ACKs from
Michael S. Tsirkin, and Maxime Coquelin. Included the virtio
issue id.
v10:
Update the conformance statement wordings from previous 'offered' form
to 'succesfully negotiated' form.
content.tex | 32
1 file changed, 32 insertions(+)
diff --git a/content.tex b/content.tex
index 4b45678..42c0568 100644
--- a/content.tex
+++ b/content.tex
@@ -3049,6 +3049,11 @@ 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 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 +3145,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
+use.
+
\begin{lstlisting}
struct virtio_net_config {
u8 mac[6];
le16 status;
le16 max_virtqueue_pairs;
+le16 mtu;
};
\end{lstlisting}
@@ -3153,6 +3163,19 @@ 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 after VIRTIO_NET_F_MTU has been successfully
+negotiated.
+
+The device MUST forward transmitted packets of up to MTU size with
+\field{gso_type} NONE or ECN, and do so without fragmentation, after
+VIRTIO_NET_F_MTU has been successfully negotiated.
+
\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 +3188,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}.
+A driver SHOULD negotiate VIRTIO_NET_F_MTU if the device offers it.
+
+If the driver negotiates VIRTIO_NET_F_MTU, it 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.
+
+If the driver negotiates VIRTIO_NET_F_MTU, it MUST NOT transmit packets of
+size exceeding the value of \field{mtu} with \field{gso_type} NONE or ECN
+
\su
Re: [virtio-dev] Re: [PATCH v9] virtio-net: add Max MTU configuration field
"Michael S. Tsirkin" <m...@redhat.com> writes: > On Tue, Sep 06, 2016 at 10:31:01AM -0400, Aaron Conole wrote: >> It is helpful for a host to indicate it's MTU to be set on guest 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. It is also helpful for sizing receive >> buffers correctly. >> >> 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. >> >> VIRTIO-152 >> Signed-off-by: Aaron Conole <acon...@redhat.com> >> Cc: Victor Kaplansky <vict...@redhat.com> >> Acked-by: Michael S. Tsirkin <m...@redhat.com> >> Acked-by: Maxime Coquelin <maxime.coque...@redhat.com> > > One technicality - please Cc virtualizat...@lists.linux-foundation.org > on anything that affects the drivers, also since that is archived more > widely. Will do, thanks. - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
Re: [virtio-dev] [PATCH v9] virtio-net: add Max MTU configuration field
"Michael S. Tsirkin" <m...@redhat.com> writes:
> On Wed, Sep 07, 2016 at 11:18:22AM +0200, Cornelia Huck wrote:
>> On Tue, 6 Sep 2016 10:31:01 -0400
>> Aaron Conole <acon...@redhat.com> wrote:
>>
>> > this as this is up for vote>
>>
>> > 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.
>>
>> I'm wondering: Do we need to distinguish between what the _driver_ does
>> and what the _guest_ does, generally speaking?
>>
>> > +
>> > \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
>> > +use.
>> > +
>> > \begin{lstlisting}
>> > struct virtio_net_config {
>> > u8 mac[6];
>> > le16 status;
>> > le16 max_virtqueue_pairs;
>> > +le16 mtu;
>> > };
>> > \end{lstlisting}
>> >
>> > @@ -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.
>>
>> Should this rather be relaxed to "after VIRTIO_NET_F_MTU has been
>> successfully negotiated"? I don't think the driver should assume
>> anything until after feature negotiation is complete.
>
> I don't think this matters much, but generally it's best
> if the config space can be read at any time.
> For example, this can allow validating MTU and not negotiating
> it if it's e.g. too small.
> Do you see value in tweaking the MTU after negotiation?
>
>
>> > +
>> > +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.
>>
>> I don't think it should be the offer that is the deciding factor, but
>> rather the final negotiation.
>
> Makes sense.
>
>> But maybe we can make this "SHOULD NOT"?
>
> It's important to make this a MUST because otherwise device
> needs to do something if it gets a bigger packet -
> e.g. fragment it, or drop it.
> With this wording, it does not have to.
>
>
>> > +
>> > +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
>> > +offers VIRTIO_NET_F_MTU.
>> > +
>> > \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.
>>
>> Again, this should be the final negotiation instead of the offer,
>> especially as...
>
> Agree here - we also c
Re: [virtio-dev] [PATCH v9] virtio-net: add Max MTU configuration field
Cornelia Huck <cornelia.h...@de.ibm.com> writes:
> On Tue, 6 Sep 2016 10:31:01 -0400
> Aaron Conole <acon...@redhat.com> wrote:
>
> this as this is up for vote>
>
>> 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.
>
> I'm wondering: Do we need to distinguish between what the _driver_ does
> and what the _guest_ does, generally speaking?
>
>> +
>> \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
>> +use.
>> +
>> \begin{lstlisting}
>> struct virtio_net_config {
>> u8 mac[6];
>> le16 status;
>> le16 max_virtqueue_pairs;
>> +le16 mtu;
>> };
>> \end{lstlisting}
>>
>> @@ -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.
>
> Should this rather be relaxed to "after VIRTIO_NET_F_MTU has been
> successfully negotiated"? I don't think the driver should assume
> anything until after feature negotiation is complete.
I agree; that was always the intent, but the wording does not convey
that. Apologies.
>> +
>> +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.
>
> I don't think it should be the offer that is the deciding factor, but
> rather the final negotiation. But maybe we can make this "SHOULD NOT"?
It really needs to be MUST NOT, but as you note above this needs to be
based on the successful negotiation of the VIRTIO_NET_F_MTU feature,
rather than just the offer.
>> +
>> +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
>> +offers VIRTIO_NET_F_MTU.
>> +
>> \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.
>
> Again, this should be the final negotiation instead of the offer,
> especially as...
>
>> +
>> +A driver SHOULD negotiate VIRTIO_NET_F_MTU if the device offers it.
>
> ...this is SHOULD and not MUST. The driver should be able to fail
> negotiating the feature if it cannot fulfill the condition above.
Agreed with both points.
>> +
>> +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
>> l
Re: [virtio-dev] [PATCH v8] virtio-net: add Max MTU configuration field
Maxime Coquelin <maxime.coque...@redhat.com> writes: > On 09/04/2016 07:50 PM, Michael S. Tsirkin wrote: >> On Sun, Sep 04, 2016 at 10:31:09AM -0400, Aaron Conole wrote: >>> > 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 part of the description is wrong now. >> It is no longer advisory and it should say "to indicate its MTU value". >> >>> > This helps in >>> > situations where the host network is using Jumbo Frames, or aiding in >>> > PMTU discovery by configuring a homogenous network. >> Maybe add >> ... It is also helpful for sizing receive buffers correctly. > Agree with Michael, I had this is in mind when looking at the > implementation. > > >>> > 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 <acon...@redhat.com> >>> > Cc: Victor Kaplansky <vict...@redhat.com> >> Acked-by: Michael S. Tsirkin <m...@redhat.com> > > FWIW: > Acked-by: Maxime Coquelin <maxime.coque...@redhat.com> Thanks so much for the review, Maxime. I've appended your ACK and resubmitted, with the changes requested by Machael. -Aaron > Thanks, > Maxime > > - > To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org > For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
Re: [virtio-dev] [PATCH v8] virtio-net: add Max MTU configuration field
"Michael S. Tsirkin" <m...@redhat.com> writes:
> On Sun, Sep 04, 2016 at 08:50:57PM +0300, Michael S. Tsirkin wrote:
>> On Sun, Sep 04, 2016 at 10:31:09AM -0400, Aaron Conole wrote:
>> > 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 part of the description is wrong now.
>> It is no longer advisory and it should say "to indicate its MTU value".
>>
>> > This helps in
>> > situations where the host network is using Jumbo Frames, or aiding in
>> > PMTU discovery by configuring a homogenous network.
>>
>> Maybe add
>> ... It is also helpful for sizing receive buffers correctly.
>>
>> > 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 <acon...@redhat.com>
>> > Cc: Victor Kaplansky <vict...@redhat.com>
>>
>> Acked-by: Michael S. Tsirkin <m...@redhat.com>
>>
>
> I created an issue to track this.
> Pls post with a fixed commit log and add
>
> VIRTIO-152
>
> on a line by itself in the log.
>
Thanks so much for the feedback, Michael. I have applied the changes
you requested, and added your ACK.
-Aaron
>> > ---
>> > 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/msg7.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.
>> >
>> > v3:
>> > Converted to just support initial MTU. Guest->host and Host->guest MTU
>> > changes are outside the scope of this change.
>> >
>> > v4:
>> > 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.
>> >
>> > v5:
>> > After feedback from Michael S. Tsirkin
>> >
>> > v6:
>> > Bit has to change to bit 25 due to an undocumented bit 24 being taken.
>> >
>> > v7:
>> > Partial rewrite with feedback from MST. Additional conformance statements
>> > added.
>> >
>> > v8:
>> > Clarified the new conformance statements.
>> >
>> > Previous series:
>> > https://lists.oasis-open.org/archives/virtio-dev/201608/msg00056.html
>> >
>> > 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
[virtio-dev] [PATCH v9] virtio-net: add Max MTU configuration field
It is helpful for a host to indicate it's MTU to be set on guest 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. It is also helpful for sizing receive
buffers correctly.
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.
VIRTIO-152
Signed-off-by: Aaron Conole <acon...@redhat.com>
Cc: Victor Kaplansky <vict...@redhat.com>
Acked-by: Michael S. Tsirkin <m...@redhat.com>
Acked-by: Maxime Coquelin <maxime.coque...@redhat.com>
---
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/msg7.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.
v3:
Converted to just support initial MTU. Guest->host and Host->guest MTU
changes are outside the scope of this change.
v4:
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.
v5:
After feedback from Michael S. Tsirkin
v6:
Bit has to change to bit 25 due to an undocumented bit 24 being taken.
v7:
Partial rewrite with feedback from MST. Additional conformance statements
added.
v8:
Clarified the new conformance statements.
v9:
Updated the commit log for correctness. Added ACKs from
Michael S. Tsirkin, and Maxime Coquelin. Included the virtio
issue id.
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
+use.
+
\begin{lstlisting}
struct virtio_net_config {
u8 mac[6];
le16 status;
le16 max_virtqueue_pairs;
+le16 mtu;
};
\end{lstlisting}
@@ -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
+offers VIRTIO_NET_F_MTU.
+
\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 th
[virtio-dev] [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 <acon...@redhat.com>
Cc: Victor Kaplansky <vict...@redhat.com>
---
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/msg7.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.
v3:
Converted to just support initial MTU. Guest->host and Host->guest MTU
changes are outside the scope of this change.
v4:
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.
v5:
After feedback from Michael S. Tsirkin
v6:
Bit has to change to bit 25 due to an undocumented bit 24 being taken.
v7:
Partial rewrite with feedback from MST. Additional conformance statements
added.
v8:
Clarified the new conformance statements.
Previous series:
https://lists.oasis-open.org/archives/virtio-dev/201608/msg00056.html
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
+use.
+
\begin{lstlisting}
struct virtio_net_config {
u8 mac[6];
le16 status;
le16 max_virtqueue_pairs;
+le16 mtu;
};
\end{lstlisting}
@@ -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
+offers VIRTIO_NET_F_MTU.
+
\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: Dev
[virtio-dev] [PATCH v7] virtio-net: add Max MTU configuration field
Sometimes it is essential for a host to be able to configure MTU
on guest's NICs to a value other than the assumed 1500 byte value.
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 transmit segment 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 <acon...@redhat.com>
Cc: Victor Kaplansky <vict...@redhat.com>
---
Previous thread:
https://lists.oasis-open.org/archives/virtio-dev/201603/msg1.html
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 | 36
1 file changed, 36 insertions(+)
diff --git a/content.tex b/content.tex
index 4b45678..4dc9beb 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
+use.
+
\begin{lstlisting}
struct virtio_net_config {
u8 mac[6];
le16 status;
le16 max_virtqueue_pairs;
+le16 mtu;
};
\end{lstlisting}
@@ -3153,6 +3166,19 @@ 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.
+
+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 gso type NONE or ECN.
+
+The device MUST forward transmitted packets of up to MTU size with
+gso type NONE or ECN, without fragmentation.
+
\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 +3191,16 @@ 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 supply enough receive buffers to be able to receive at least
+one receive packet with gso type NONE or ECN.
+
+A driver SHOULD negotiate VIRTIO_NET_F_MTU if the device offers it.
+
+A driver MUST honor \field{mtu} if it negotiates VIRTIO_NET_F_MTU.
+
+A driver MUST NOT transmit packets of size exceeding the value of \field{mtu}
+with gso type NONE or ECN, if it negotiates VIRTIO_NET_F_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.5
-
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] [PATCH v6] virtio-net: add mtu configuration field
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
when a new MTU is assigned by the guest OS.
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 <acon...@redhat.com>
Cc: Victor Kaplansky <vict...@redhat.com>
---
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/msg7.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.
v3:
Converted to just support initial MTU. Guest->host and Host->guest MTU
changes are outside the scope of this change.
v4:
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.
v5:
After feedback from Michael S. Tsirkin
v6:
Bit has to change to bit 25 due to an undocumented bit 24 being taken.
content.tex | 22 ++
1 file changed, 22 insertions(+)
diff --git a/content.tex b/content.tex
index d989d98..10944ec 100644
--- a/content.tex
+++ b/content.tex
@@ -3078,6 +3078,14 @@ features.
\item[VIRTIO_NET_F_CTRL_MAC_ADDR(23)] Set MAC address through control
channel.
+
+\item[VIRTIO_NET_F_MTU(25)] 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 MTU value supplied to the operating system.
+
+Note: many operating systems override the MTU value provided by the
+driver.
\end{description}
\subsubsection{Feature bit requirements}\label{sec:Device Types / Network
Device / Feature bits / Feature bit requirements}
@@ -3132,11 +3140,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 MTU for the driver to
+use.
+
\begin{lstlisting}
struct virtio_net_config {
u8 mac[6];
le16 status;
le16 max_virtqueue_pairs;
+le16 mtu;
};
\end{lstlisting}
@@ -3145,6 +3158,11 @@ 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.
+
\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 +3175,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. A driver
+MUST use \field{mtu} if it negotiates VIRTIO_NET_F_MTU. A driver MUST NOT
+negotiate VIRTIO_NET_F_MTU if it does not use \field{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-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
