RE: [PATCH v10 2/2] virtio-net: Define Accurate ECN feature in virtio-spec

> From: Mirja Kuehlewind <[email protected]>
> 
> The draft is final and approved. The next "version" will be RFC9768 with some
> minor editorial changes. We are only waiting for the final approval of one
> author otherwise this is ready to publish as RFC.
>
This is good. Thanks for the confirmation.
Continuing rest of the review.
 
> On 29.09.25, 13:01, "Parav Pandit" <[email protected]
> <mailto:[email protected]>> wrote:
> 
> 
> > From: [email protected]
> > <mailto:[email protected]> <chia-yu.chang@nokia-bell-
> > labs.com>
> >
> > From: Chia-Yu Chang <[email protected]
> > <mailto:[email protected]>>
> >
> > This change implements Accurate ECN based on the AccECN specification
> > (RFC-to-be 9768):
> >
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
> > s.ietf.org%2Fid%2Fdraft-ietf-tcpm-accurate-ecn-34.txt&data=05%7C02%7Cp
> >
> arav%40nvidia.com%7Caed29967ec87454c35e208ddff50d6ef%7C43083d1572
> 7340c
> >
> 1b7db39efd9ccc17a%7C0%7C0%7C638947444875846641%7CUnknown%7CT
> WFpbGZsb3d
> >
> 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI
> joiT
> >
> WFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=I8SBCd4SV%2FJHeW0tf
> djMvoZNp
> > i4OerT04rdKAf7qlyI%3D&reserved=0
> > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftoo
> > ls.ietf.org%2Fid%2Fdraft-ietf-tcpm-accurate-ecn-34.txt&data=05%7C02%7C
> >
> parav%40nvidia.com%7Caed29967ec87454c35e208ddff50d6ef%7C43083d157
> 27340
> >
> c1b7db39efd9ccc17a%7C0%7C0%7C638947444875883972%7CUnknown%7CT
> WFpbGZsb3
> >
> d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF
> OIjoi
> >
> TWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=XIvEjEX%2Fpa6FH8%2
> BOs0nwzq
> > vdOZgfMqHeXJYJ1jHNUiM%3D&reserved=0>
> >
> is this approved IETF draft or there is next version after this?
> Suggested link indicates that this draft expires on 11th this month.
> 
> 
> 
> 
> > Unlike RFC3168 ECN, Accurate ECN uses the TCP CWR flag as part of the
> > ACE field to count new packets with CE marks in the IP-ECN field;
> > however, RFC
> > 3168 ECN-aware TSO will clean the TCP CWR flag from the 2nd segment of
> > an aggregated segment. Therefore, fallback shall be applied by setting
> > NETIF_F_GSO_ACCECN to ensure that the CWR flag should not be changed
> > within the aggregated segment (e.g., super-skb in Linux).
> >
> It would be to add the link in commit message to NETIF_F_GSO_ACCECN
> Linux kernel documentation.
> 
> 
> > To apply it in virtio-spec, new feature bits for host and guest are
> > added for feature negotiation between driver and device. And the
> > translation of the Accurate ECN GSO flag between virtio_net_hdr and
> > skb header for NETIF_F_GSO_ACCECN is also added to avoid CWR flag
> > corruption due to
> > RFC3168 ECN TSO.
> >
> > Signed-off-by: Chia-Yu Chang <[email protected]
> > <mailto:[email protected]>>
> > ---
> > device-types/net/description.tex | 54 +++++++++++++++++++++++++-------
> > introduction.tex | 3 ++
> > 2 files changed, 46 insertions(+), 11 deletions(-)
> >
> > diff --git a/device-types/net/description.tex b/device-
> > types/net/description.tex index 0da8f9f..6761148 100644
> > --- a/device-types/net/description.tex
> > +++ b/device-types/net/description.tex
> > @@ -150,6 +150,15 @@ \subsection{Feature bits}\label{sec:Device Types
> > / Network Device / Feature bits when VIRTIO_NET_F_IPSEC is negotiated.
> > When a device offers IPsec feature, it SHOULD also offer the
> > VIRTIO_NET_F_OUT_NET_HEADER feature.
> >
> > +\item[VIRTIO_NET_F_HOST_ACCECN (71)] Device can receive TSO and
> > +follow  the requirements of the ACE field described in  ``Section
> > +3.3.4 . Requirements for TCP Segmentation Offload and Large
> > Receive Offload''
> > + of \hyperref[intro:accecn]{[AccECN]}.
> > +
> > +\item[VIRTIO_NET_F_GUEST_ACCECN (72)] Driver can receive TSO and
> > follow
> > + the requirements of the ACE field described in ``Section 3.3.4 .
> > + Requirements for TCP Segmentation Offload and Large
> > Receive Offload''
> > + of \hyperref[intro:accecn]{[AccECN]}.
> > \end{description}
> >
> > \subsubsection{Feature bit requirements}\label{sec:Device Types /
> > Network Device / Feature bits / Feature bit requirements} @@ -161,6
> > +170,7 @@ \subsubsection{Feature bit requirements}\label{sec:Device
> > Types / Network Device \item[VIRTIO_NET_F_GUEST_TSO4] Requires
> > VIRTIO_NET_F_GUEST_CSUM.
> > \item[VIRTIO_NET_F_GUEST_TSO6] Requires VIRTIO_NET_F_GUEST_CSUM.
> > \item[VIRTIO_NET_F_GUEST_ECN] Requires VIRTIO_NET_F_GUEST_TSO4 or
> > VIRTIO_NET_F_GUEST_TSO6.
> > +\item[VIRTIO_NET_F_GUEST_ACCECN] Requires
> > VIRTIO_NET_F_GUEST_TSO4 or VIRTIO_NET_F_GUEST_TSO6.
> > \item[VIRTIO_NET_F_GUEST_UFO] Requires VIRTIO_NET_F_GUEST_CSUM.
> > \item[VIRTIO_NET_F_GUEST_USO4] Requires VIRTIO_NET_F_GUEST_CSUM.
> > \item[VIRTIO_NET_F_GUEST_USO6] Requires VIRTIO_NET_F_GUEST_CSUM.
> > @@ -171,6 +181,7 @@ \subsubsection{Feature bit
> > requirements}\label{sec:Device Types / Network Device
> > \item[VIRTIO_NET_F_HOST_TSO4] Requires VIRTIO_NET_F_CSUM.
> > \item[VIRTIO_NET_F_HOST_TSO6] Requires VIRTIO_NET_F_CSUM.
> > \item[VIRTIO_NET_F_HOST_ECN] Requires VIRTIO_NET_F_HOST_TSO4 or
> > VIRTIO_NET_F_HOST_TSO6.
> > +\item[VIRTIO_NET_F_HOST_ACCECN] Requires VIRTIO_NET_F_HOST_TSO4
> > or VIRTIO_NET_F_HOST_TSO6.
> > \item[VIRTIO_NET_F_HOST_UFO] Requires VIRTIO_NET_F_CSUM.
> > \item[VIRTIO_NET_F_HOST_USO] Requires VIRTIO_NET_F_CSUM.
> > \item[VIRTIO_NET_F_HOST_UDP_TUNNEL_GSO] Requires
> > VIRTIO_NET_F_HOST_TSO4, VIRTIO_NET_F_HOST_TSO6 @@ -294,11
> > +305,11 @@ \subsection{Device configuration layout}\label{sec:Device
> > +Types
> > / Network Device 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
> > +level ethernet header length) size with \field{gso_type} NONE, ECN or
> > +ACCECN
> > 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
> > +level ethernet header length) size with \field{gso_type} NONE, ECN or
> > +ACCECN, and do
> > so without fragmentation, after VIRTIO_NET_F_MTU has been successfully
> > negotiated.
> >
> > @@ -348,11 +359,11 @@ \subsection{Device configuration
> > layout}\label{sec:Device Types / Network Device
> >
> > If the driver negotiates VIRTIO_NET_F_MTU, it MUST supply enough
> > receive buffers to receive at least one receive packet of size
> > \field{mtu} (plus low -level ethernet header length) with \field{gso_type}
> NONE or ECN.
> > +level ethernet header length) with \field{gso_type} NONE, ECN or ACCECN.
> >
> > If the driver negotiates VIRTIO_NET_F_MTU, it MUST NOT transmit
> > packets of size exceeding the value of \field{mtu} (plus low level
> > ethernet header length) - with \field{gso_type} NONE or ECN.
> > +with \field{gso_type} NONE, ECN or ACCECN.
> >
> > A driver SHOULD negotiate the VIRTIO_NET_F_STANDBY feature if the
> > device offers it.
> >
> > @@ -443,7 +454,7 @@ \subsection{Device
> > Initialization}\label{sec:Device Types / Network Device / Dev The
> > VIRTIO_NET_F_GUEST_CSUM feature indicates that partially checksummed
> > packets can be received, and if it can do that then the
> > VIRTIO_NET_F_GUEST_TSO4, VIRTIO_NET_F_GUEST_TSO6,
> > - VIRTIO_NET_F_GUEST_UFO, VIRTIO_NET_F_GUEST_ECN,
> > VIRTIO_NET_F_GUEST_USO4,
> > + VIRTIO_NET_F_GUEST_UFO, VIRTIO_NET_F_GUEST_ECN,
> > + VIRTIO_NET_F_GUEST_ACCECN, VIRTIO_NET_F_GUEST_USO4,
> > VIRTIO_NET_F_GUEST_USO6 VIRTIO_NET_F_GUEST_UDP_TUNNEL_GSO
> and
> > VIRTIO_NET_F_GUEST_UDP_TUNNEL_GSO_CSUM are the input equivalents
> of
> > the features described above.
> > @@ -613,6 +624,7 @@ \subsection{Device Operation}\label{sec:Device
> > Types / Network Device / Device O #define
> > VIRTIO_NET_HDR_GSO_UDP_TUNNEL_IPV4 0x20 #define
> > VIRTIO_NET_HDR_GSO_UDP_TUNNEL_IPV6 0x40 #define
> VIRTIO_NET_HDR_GSO_ECN
> > 0x80
> > +#define VIRTIO_NET_HDR_GSO_ACCECN 0x10
> > u8 gso_type;
> > le16 hdr_len;
> > le16 gso_size;
> > @@ -737,6 +749,13 @@ \subsubsection{Packet
> > Transmission}\label{sec:Device Types / Network Device / De has the CWR
> > flag set and follows the requirements of the CWR flag described in
> > ``Section 6.1.2. The TCP Sender'' of \hyperref[intro:rfc3168]{[RFC3168]}.
> > \footnote{This case is not handled by some older hardware, so is
> > called out specifically in the protocol.}.
> > +
> > + \item If the driver negotiated the VIRTIO_NET_F_HOST_ACCECN feature,
> > + the VIRTIO_NET_HDR_GSO_ACCECN bit in \field{gso_type} indicates that
> > the TCP packet
> > + follows the requirements of the ACE field described in ``Section
> > + 3.3.4 . Requirements for TCP Segmentation Offload and Large
> > Receive Offload''
> > + of \hyperref[intro:accecn]{[AccECN]}.
> > + \footnote{This case is not handled by some older hardware, so is
> > + called out
> > specifically in the protocol.}.
> > \end{itemize}
> >
> > \item If the driver negotiated the VIRTIO_NET_F_HOST_UDP_TUNNEL_GSO
> > feature and the @@ -837,6 +856,12 @@ \subsubsection{Packet
> > Transmission}\label{sec:Device Types / Network Device / De of
> > \hyperref[intro:rfc3168]{[RFC3168]}, unless the VIRTIO_NET_F_HOST_ECN
> > feature is negotiated, in which case the driver MUST set the
> > VIRTIO_NET_HDR_GSO_ECN bit in \field{gso_type}.
> >
> > +The driver SHOULD NOT send to the device TCP packets requiring
> > +segmentation offload which need to follow the ACE field requirements
> > +described in ``Section 3.3.4 . Requirements for TCP Segmentation
> > +Offload and
> > Large Receive Offload''
> > +of \hyperref[intro:accecn]{[AccECN]}, unless the
> > +VIRTIO_NET_F_HOST_ACCECN feature is negotiated, in which case the
> > +driver
> > MUST set the VIRTIO_NET_HDR_GSO_ACCECN bit in \field{gso_type}.
> > +
> > If VIRTIO_NET_F_HOST_UDP_TUNNEL_GSO is negotiated, the driver MAY
> set
> > VIRTIO_NET_HDR_GSO_UDP_TUNNEL_IPV4 bit or the
> > VIRTIO_NET_HDR_GSO_UDP_TUNNEL_IPV6 bit in \field{gso_type} according
> > to the inner network header protocol type @@ -1171,12 +1196,12 @@
> > \subsubsection{Processing of Incoming Packets}\label{sec:Device Types
> > / Network value to indicate the outer network header offset in packet.
> > \end{enumerate}
> >
> > -Additionally, VIRTIO_NET_F_GUEST_CSUM, TSO4, TSO6, UDP, UDP_TUNNEL
> > -and ECN features enable receive checksum, large receive offload and
> > RFC3168 -ECN support which are the input equivalents of the transmit
> > checksum, - transmit segmentation offloading and RFC3168 ECN features,
> > as described -in \ref{sec:Device Types / Network Device / Device
> > Operation / -Packet
> > Transmission}:
> > +Additionally, VIRTIO_NET_F_GUEST_CSUM, TSO4, TSO6, UDP,
> UDP_TUNNEL,
> > ECN
> > +and ACCECN features enable receive checksum, large receive offload,
> > +RFC3168 ECN and Accurate ECN support which are the input equivalents
> > +of the transmit checksum, transmit segmentation offloading, RFC3168
> > +ECN and Accurate ECN features, as described in \ref{sec:Device Types
> > +/ Network Device / Device Operation / Packet Transmission}:
> > \begin{enumerate}
> > \item If the VIRTIO_NET_F_GUEST_TSO4, TSO6, UFO, USO4 or USO6 options
> > were negotiated, then \field{gso_type} MAY be something other than @@
> > -
> > 1286,6 +1311,12 @@ \subsubsection{Processing of Incoming
> > Packets}\label{sec:Device Types / Network if packet contains a valid
> > network header. Otherwise, the device MUST not use
> \field{outer_nh_offset}.
> >
> > +The device SHOULD NOT send to the driver TCP packets requiring
> > +segmentation offload which need to follow the ACE field requirements
> > +described in ``Section 3.3.4 . Requirements for TCP Segmentation
> > +Offload and
> > Large Receive Offload''
> > +of \hyperref[intro:accecn]{[AccECN]}, unless the
> > +VIRTIO_NET_F_GUEST_ACCECN feature is negotiated, in which case the
> > device MUST set the VIRTIO_NET_HDR_GSO_ACCECN bit in \field{gso_type}.
> > +
> > If the VIRTIO_NET_F_GUEST_CSUM feature has been negotiated, the device
> > MAY set the VIRTIO_NET_HDR_F_NEEDS_CSUM bit in \field{flags}, if so:
> > @@ -2286,6 +2317,7 @@ \subsubsection{Control
> > Virtqueue}\label{sec:Device Types / Network Device / Devi #define
> > VIRTIO_NET_F_GUEST_UDP_TUNNEL_GSO_CSUM 47 #define
> > VIRTIO_NET_F_GUEST_USO4 54 #define VIRTIO_NET_F_GUEST_USO6 55
> > +#define VIRTIO_NET_F_GUEST_ACCECN 70
> >
> > #define VIRTIO_NET_CTRL_GUEST_OFFLOADS 5 #define
> > VIRTIO_NET_CTRL_GUEST_OFFLOADS_SET 0 diff --git a/introduction.tex
> > b/introduction.tex index 1c4cb33..fabefe4 100644
> > --- a/introduction.tex
> > +++ b/introduction.tex
> > @@ -183,6 +183,9 @@ \section{Normative
> References}\label{sec:Normative
> > References} \phantomsection\label{intro:rfc3168}\textbf{[RFC3168]} &
> > S. Floyd., ``The Addition of Explicit Congestion Notification (ECN) to
> > IP'', September 2001.
> >
> > \newline\url{http://h/ <http://h/>
> > ttp%3A%2F%2Fwww.ietf.org%2Frfc%2Frfc3168.txt&data=05%7C02%7Cpara
> > v%40nvidia.com%7Ccd0d940b2c75467aded808dddb2a55ed%7C43083d15
> > 727340c1b7db39efd9ccc17a%7C0%7C0%7C638907697092805411%7CUn
> > known%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw
> > MCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%
> > 7C&sdata=q85q1Dlh1v%2Bvf5PUA4D3KlNdTkm6FNhy701It%2BS7648%3D
> > &reserved=0}\\
> > + \phantomsection\label{intro:accecn}\textbf{[AccECN]} & B. Briscoe.,
> > + ``More Accurate Explicit Congestion Notification (AccECN)
> > Feedback in TCP'', March 2025.
> > +
> > + \newline\url{http://https/ <http://https/>
> > + %3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-tcpm-accurate-
> > ecn-34
> > +
> > .txt&data=05%7C02%7Cparav%40nvidia.com%7Ccd0d940b2c75467aded80
> > 8dddb2a5
> > +
> > 5ed%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C6389076970
> > 92821586%7C
> > +
> > Unknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMD
> > AwMCIsIlAi
> > +
> > OiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdat
> > a=nFBacE
> > + %2BDuwZTbFR6kPuHdJaBt3tWOLzUjrLsYDyRKso%3D&reserved=0}\\
> > \end{longtable}
> >
> > \section{Non-Normative References}
> > --
> > 2.34.1
> >
> 
> 
> 
>