Re: [PATCH v5 net-next 1/2] net: update comments for SKB_GSO_TCP_ECN and SKB_GSO_TCP_ACCECN
Jakub Kicinski <[email protected]>
| Newsgroups | org.kernel.vger.linux-rdma,dev.linux.lists.virtualization,org.kernel.vger.bpf,org.kernel.vger.linux-doc,org.kernel.vger.linux-kselftest,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?