Re: [PATCH net-next v2 2/4] net: gso: support bounded TCP segmentation
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: 2026-09-21 20:36:40
Wang Zhan wrote:
On Sat, 19 Sep 2026 11:35:17 -0400 Willem de Bruijn wrote:quoted
quoted
- struct sk_buff *segs = __skb_gso_segment(skb, features, false); + struct sk_buff *segs; struct sk_buff *next; + segs = __skb_gso_segment(skb, features, false, 0);irrelevant?Not unrelated: with the extra argument that line is 82 columns, so the initializer moved to its own line. The call itself is unchanged.quoted
quoted
+ unsigned int max_segs = SKB_GSO_CB(head_skb)->max_segs;could this be computed inside skb_segment, rather than having to be passed through SKB_GSO_CB. I haven't checked, but it would simplify.I tried it: https://github.com/zwtop/linux/pull/3 It does read better, but whether to resegment is the caller's choice: the qdiscs strip the GSO bits to get one packet per segment (sch_netem.c:443), and a device-derived limit groups that output instead - which sch_netem then drops, because skb_checksum_help() on the first segment rejects a GSO skb (sch_netem.c:538, net/core/dev.c:3626).
So this is a rare netem edge case we need to handle. In the hot path, we should be able to defer the decision whether to segment entirely or segment to the capabilities of the device to skb_segment itself.
The features cannot tell the two cases apart either: gso_features_check() clears the same bits for an over-limit skb (net/core/dev.c:3843).
I wonder if we can refine this instead.
So the bound stays an input from the caller.