Wang Zhan wrote: > 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.
Precomputing in the caller, as the current series does, is fine too, if some caller-specific context is needed. I'm mostly concerned about duplicating logic and the number of functions touched in this series. But skb_segment itself is too complex already, so preferable to minimize complication there. (The reuse of partial for this purpose is very neat.) If only validate_xmit_skb allows this, because all other segmentation callers do want full segmentation (not checked, but I can believe that), the current approach is fine. If we can clean up the repeated tests and simplify the code in general. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
