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
