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

[Jakub Kicinski <kuba@kernel.org>]

On Fri, 14 Aug 2026 09:34:01 -0400 Willem de Bruijn wrote:
> > Current SW GRO sets SKB_GSO_TCP_ACCECN when the flushed skb carries CWR in tcp_gro_complete():
> > if (th->cwr)
> >     shinfo->gso_type |= SKB_GSO_TCP_ACCECN;  
> 
> And I suppose it follows correct AccECN rules for coalescing.
> 
> That is a performance regression from RFC 3168 ECN, as it allows for
> less effective coalescing. I have no intuition how much it will
> differ in practice.
> 
> > For HW GRO of a legacy device that implementing RFC3168 semantics, setting SKB_GSO_TCP_ECN seems reasonable.
> > However, such a device would not be able to preserve ACCECN signaling across the GRO/GSO.
> > In that case, if preserving AccECN signaling is required, disabling HW GRO may indeed be necessary.  
> 
> Right.

I'm still not following.. Maybe Willem can ELI5 what the problem is.

_SW_ GRO follows only the AccECN rules.
But if HW GRO follows RFC 3168 and we mark the aggregate as
SKB_GSO_TCP_ECN - TSO will also abide, and segmented output 
will be identical to pre-GRO input.

Are we trying to ban RFC 3168 behavior in HW purely to match SW?

> And there currently is no kernel API to disable only ECN
> coalescing. NETIF_F_GRO_HW enables or disables HW-GRO entirely.
> Or even to signal whether a HW-GRO implementation is AccECN
> capable.
> 
> Disabling HW-GRO can be a huge efficiency regression. I suspect
> many users will prioritize the efficiency over preserving the AccECN
> signal.
> 
> That said, some devices may have other ways to configure such
> finer details of their HW-GRO, even though not available through
> Ethtool.