On 2026-09-24 23:26:27 [+0200], Xin Xie wrote: > On 23/09/2026 12:43, Sebastian Andrzej Siewior wrote: > > 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
