On 2026-09-25 11:52:52 [+0200], Xin Xie wrote: … > A veth pair is simply an in-kernel memory pipe. When a large TCP skb > arrives at prp0-peer, veth does not trigger TSO or software segmentation, > it simply hands over the intact skb pointer directly to prp0-int. > > Turning GRO off on prp0-int does not force prp0-peer to split it. I > confirmed this with ordinary TCP traffic in a VM, with GRO off on both > veth ends.
So veth. The test suite is using veth I don't remember that it was (is) a problem there. But then there is no TCP. Wouldn't it be also a problem if you attach veth interface to a bridge and that large TCP skb would have to leave the bridge via a physical port? This does not sound like it is limited to hsr. I think it deserves a helper similar to skb_linearize(). > Patch 3 splits that skb before PRP assigns sequence numbers and adds > RCTs. Each resulting frame needs its own sequence number and RCT. > Ordinary non-GSO skbs skip the segmentation path. > > In addition, if GRO disablement fails (e.g., buggy drivers or > hardware-fixed GRO_HW that cannot be turned off via ethtool), Patch 3 > also acts as a fallback defense for these edge cases. > Sebastian
