Re: [PATCH 3/4] net: hsr: unfold GSO super-packets at the forward entry

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

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