Re: [PATCH 3/4] net: hsr: unfold GSO super-packets at the forward entry
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: 2026-09-25 08:29:57
Also in:
linux-kselftest, lkml, stable
On 2026-09-24 23:26:27 [+0200], Xin Xie wrote:
On 23/09/2026 12:43, Sebastian Andrzej Siewior wrote:quoted
Wouldn't it be simpler to not allow such packets?For master TX, yes: removing GSO features lets the core segment before ndo_start_xmit(), as patch 3 already does. The interlink RX path is different. With GRO/GRO_HW disabled, it can still receive skbs that were already GSO at the sender. I reproduced this with ordinary TCP traffic over veth in a VM. Rejecting these skbs would drop valid traffic.
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'll retain segmentation for valid interlink GSO in the ordered consumer described in my patch 2 reply, before per-frame sequence allocation and HSR tag/PRP RCT construction. Each aggregate would finish before the next input, without holding an HSR lock across segmentation or transmission.
Sebastian