On Mon, 21 Sep 2026 16:36:37 -0400 Willem de Bruijn wrote: > Wang Zhan wrote: >> 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). >> 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. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
