RE: [PATCH v11 1/2] virtio-net: Clarify ECN and GSO_ECN descriptions

> -----Original Message-----
> From: Jason Wang <[email protected]> 
> Sent: Wednesday, February 4, 2026 3:05 AM
> To: Chia-Yu Chang (Nokia) <[email protected]>
> Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Koen De Schepper (Nokia) <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
> Subject: Re: [PATCH v11 1/2] virtio-net: Clarify ECN and GSO_ECN descriptions
> 
> 
> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
> 
> 
> 
> On Wed, Feb 4, 2026 at 12:21 AM <[email protected]> wrote:
> >
> > From: Chia-Yu Chang <[email protected]>
> >
> > The existing specification that describing VIRTIO_NET_F_*_ECN and 
> > VIRTIO_NET_HDR_GSO_ECN can be misinterpreted as reffering to the IP 
> > ECN field. In reality, VIRTIO_NET_HDR_GSO_ECN corresponds to the TCP 
> > CWR flag and indicates that segment offload must follow the rules 
> > defined in
> > RFC3168 Section 6.1.2: the first emitted segment retains the CWR flag, 
> > and all subsequent segments must clear it.
> >
> > This patch updates ECN feature descriptions and the transmit/receive 
> > requirements to accurately reflect the intended behavior explicitly 
> > specified in RFC3168.
> >
> > For detailed requirements, see RFC3168:
> > https://datatracker.ietf.org/doc/html/rfc3168
> >
> > Signed-off-by: Chia-Yu Chang <[email protected]>
> > ---
> >  device-types/net/description.tex | 35 +++++++++++++++++---------------
> >  introduction.tex                 |  3 +++
> >  2 files changed, 22 insertions(+), 16 deletions(-)
> >
> > diff --git a/device-types/net/description.tex 
> > b/device-types/net/description.tex
> > index da9ff17..0da8f9f 100644
> > --- a/device-types/net/description.tex
> > +++ b/device-types/net/description.tex
> > @@ -54,7 +54,9 @@ \subsection{Feature bits}\label{sec:Device Types / 
> > Network Device / Feature bits
> >
> >  \item[VIRTIO_NET_F_GUEST_TSO6 (8)] Driver can receive TSOv6.
> >
> > -\item[VIRTIO_NET_F_GUEST_ECN (9)] Driver can receive TSO with ECN.
> > +\item[VIRTIO_NET_F_GUEST_ECN (9)] Driver can receive TSO with the CWR flag set
> > +    and follow the requirements of the CWR bit described in
> > +    ``Section 6.1.2. The TCP Sender'' of \hyperref[intro:rfc3168]{[RFC3168]}.
> >
> >  \item[VIRTIO_NET_F_GUEST_UFO (10)] Driver can receive UFO.
> >
> > @@ -62,7 +64,9 @@ \subsection{Feature bits}\label{sec:Device Types / 
> > Network Device / Feature bits
> >
> >  \item[VIRTIO_NET_F_HOST_TSO6 (12)] Device can receive TSOv6.
> >
> > -\item[VIRTIO_NET_F_HOST_ECN (13)] Device can receive TSO with ECN.
> > +\item[VIRTIO_NET_F_HOST_ECN (13)] Device can receive TSO with the CWR flag set
> > +    and follow the requirements of the CWR bit described in
> > +    ``Section 6.1.2. The TCP Sender'' of \hyperref[intro:rfc3168]{[RFC3168]}.
> >
> >  \item[VIRTIO_NET_F_HOST_UFO (14)] Device can receive UFO.
> >
> > @@ -729,9 +733,10 @@ \subsubsection{Packet Transmission}\label{sec:Device Types / Network Device / De
> >      header (ie. MSS).
> >
> >    \item If the driver negotiated the VIRTIO_NET_F_HOST_ECN feature,
> > -    the VIRTIO_NET_HDR_GSO_ECN bit in \field{gso_type}
> > -    indicates that the TCP packet has the ECN bit set\footnote{This case is not handled by some older hardware, so is called out
> > -specifically in the protocol.}.
> > +    the VIRTIO_NET_HDR_GSO_ECN bit in \field{gso_type} indicates that the TCP packet
> > +    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.}.
> >     \end{itemize}
> >
> >  \item If the driver negotiated the VIRTIO_NET_F_HOST_UDP_TUNNEL_GSO 
> > feature and the @@ -828,10 +833,9 @@ \subsubsection{Packet 
> > Transmission}\label{sec:Device Types / Network Device / De  \field{gso_type} to VIRTIO_NET_HDR_GSO_UDP_L4.
> >
> >  The driver SHOULD NOT send to the device TCP packets requiring segmentation offload
> > -which have the Explicit Congestion Notification bit set, 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}.
> > +which need to follow the CWR flag requirements described in ``Section 6.1.2. The TCP Sender''
> > +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}.
> 
> I wonder if it's better to have some compatibility description here instead of removing the old ECN completely.
> [...]

Hi Jason,

I was still thinking to remove old ECN descriptions, because it is not correct.
As the GSO flags here was to properly handle TCP CWR flag, not ECN bit in IP.

But, maybe adding another paragraph below (pls see below proposal) can fulfill your request?

"Earlier versions of this specification, and some existing implementations,
described GSO_ECN in terms of the IP ECN field rather than the TCP CWR flag.
Devices MAY continue to accept packets where the CWR flag is not set but the
\texttt{VIRTIO_NET_HDR_GSO_ECN} bit is present, treating such packets as if
ECN offload were not requested. Drivers, however, MUST use
\texttt{VIRTIO_NET_HDR_GSO_ECN} only to indicate the presence of the
TCP CWR flag and MUST NOT set it solely due to the IP ECN field."


And if we have to implement this MAY feature in virtio_net.h of Linux, we then need to fetch TCP header (Or any other suggested way?).

Thanks!
Chia-Yu