Thread (27 messages) 27 messages, 5 authors, 2d ago

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.


Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help