On Fri, Aug 14, 2026 at 3:01 PM Jakub Kicinski <[email protected]> wrote: > > 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.
+1 > Are we trying to ban RFC 3168 behavior in HW purely to match SW? I think that's the intent here? > > > 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.
