Re: [PATCH net-next v2 2/4] net: gso: support bounded TCP segmentation

[Willem de Bruijn <willemdebruijn.kernel@gmail.com>]

Wang Zhan wrote:
> On Sat, 19 Sep 2026 11:35:17 -0400 Willem de Bruijn wrote:
> > > -		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.
> 
> > > +	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.