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

[Xin Xie <xiexinet@gmail.com>]

On 25/09/2026 10:29, Sebastian Andrzej Siewior wrote:
> So you disable GRO on the interlink port and still receive GRO packets?
> Or is this performance related where you want to keep GRO enabled on the
> interlink port?
I am not trying to keep GRO enabled for performance. The difference
is between a physical interlink and a veth interlink.

With a physical interlink, TCP data is split into packets before it
goes onto the wire via TSO/GSO. If GRO is off at the receiver, this
interlink RX path needs no extra segmentation. Patch 3 is indeed
unnecessary in this case.

With a veth interlink, there is no physical wire:
TCP -> prp0-peer -> prp0-int (interlink) -> PRP

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.

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.

--
Xin