Re: [PATCH v5 net-next 1/2] net: update comments for SKB_GSO_TCP_ECN and SKB_GSO_TCP_ACCECN

Jakub Kicinski <[email protected]> Tue, 11 Aug 2026 17:30:17 -0700
Newsgroups dev.linux.lists.virtualization,org.kernel.vger.bpf,org.kernel.vger.linux-doc,org.kernel.vger.linux-kselftest,org.kernel.vger.linux-rdma,org.kernel.vger.netdev
Message-ID <[email protected]>
On Tue,  4 Aug 2026 23:35:09 +0200 [email protected]
wrote:
> This corresponds to discussions in virtio mailing list:
> https://lore.kernel.org/all/[email protected]/
> 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?