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.
