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

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

From: Wang Zhan <hidden>
Date: 2026-09-23 09:45:32

On Mon, 21 Sep 2026 16:36:37 -0400 Willem de Bruijn wrote:
Wang Zhan wrote:
quoted
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.
That is only one example.  I have not checked every caller, but at least tc
sched tbf/cake and the OVS upcall are as well.
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.
Deciding it entirely inside skb_segment(), without passing extra
information, is difficult: the oversize case overlaps with the cases above.
And the features we pass in may also have had NETIF_F_GSO_MASK cleared, so
it would have to take the device from skb->dev (that should not be much of a
problem if we only handle the TX path).
quoted
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.
Maybe we can add a bool to skb_gso_cb saying whether GSO output is allowed,
and leave it to skb_segment() to decide whether a GSO packet is actually
emitted, and the max-segs.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help