> -----Original Message----- > From: Jakub Kicinski <[email protected]> > Sent: Wednesday, August 12, 2026 2:30 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]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [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]; Parav Pandit <[email protected]> > Subject: Re: [PATCH v5 net-next 1/2] net: update comments for SKB_GSO_TCP_ECN > and SKB_GSO_TCP_ACCECN > > > 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 Tue, 4 Aug 2026 23:35:09 +0200 [email protected] > wrote: > > This corresponds to discussions in virtio mailing list: > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore > > .kernel.org%2Fall%2F20250814120118.81787-1-chia-yu.chang%40nokia-bell- > > labs.com%2F&data=05%7C02%7Cchia-yu.chang%40nokia-bell-labs.com%7C150b5 > > 1c3733640dd2cde08def808e48f%7C5d4717519675428d917b70f44f9630b0%7C0%7C0 > > %7C639220914236399114%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs > > IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7 > > C0%7C%7C%7C&sdata=jGSBo1wXJOnjulVOJKW3PAEbrUAq7X30Zax4SBJ6VRQ%3D&reser > > ved=0 And it was suggested to clarify SKB_GSO_TCP_ECN and > > SKB_GSO_TCP_ACCECN. > > > - /* This indicates the tcp segment has CWR set. */ > > + /* For TX, this indicates that the first TCP segment has CWR set, and > > + * any subsequent segment in the same skb has CWR cleared. This flag > > + * must not be used in RX, because the connection to which the segment > > + * belongs is not tracked to use RFC3168 or AccECN. Using RFC3168 ECN > > + * offload may clear CWR and corrupt ACE signal (CWR is part of it). > > + * Instead, SKB_GSO_TCP_ACCECN shall be used to avoid CWR corruption. > > + */ > > I still can't wrap my head around this TBH. > > SKB_GSO_TCP_ECN means RFC3168 > SKB_GSO_TCP_ACCECN means AccECN > > If the HW can correctly detect cwr on first frame and then no cwr and report > that as ECN/RFC3168 - what's the problem? TSO will produce the exact expected > segment sequence. > > Is the program that if we re-GRO that frame in SW we end up with > ECN+ACCECN on the same skb?
Yes, this is the problem. The HW does not know whether the received packets belong to an RFC3168 ECN flow or an AccECN flow on the RX path. For example, HW GRO may set SKB_GSO_TCP_ECN after observing that the first packet has CWR=1: +===================+==========+=================+================+ | Packet id | CWR flag | Flag | Flushed as SKB | +===================+==========+=================+================+ | 0 | 1 | SKB_GSO_TCP_ECN | 0 | | 1 | 0 | - | 0 | | 2 | 1 | - | 0 | | 3 | 1 | - | 1 | +===================+==========+=================+================+ If the aggregated skb is forwarded through a device using GSO, e.g., HW RX (GRO) -> veth TX (GSO), the SKB_GSO_TCP_ECN applies RFC3168 semantics. This means that only the 1st segment keeps the CWR flag while all subsequent segments have CWR cleared: +===================+==========+ | Packet id | CWR flag | +===================+==========+ | 0 | 1 | | 1 | 0 | | 2 | 0 | | 3 | 0 | +===================+==========+ This behavior is ok for RFC3168, since CWR is expected to appear only once. However, for AccECN, CWR is part of the ACE signal and must be preserved across all segments. In the example above, the original CWR sequence was 1,0,1,1. But after re-segmentation it becomes: 1,0,0,0. This is why SKB_GSO_TCP_ECN should not be used in RX/GRO paths. -- Chia-Yu
