On Fri, Jul 31, 2026 at 11:02:19AM +0200, Xin Xie wrote: > [PATCH net v3 0/4] net: hsr: fix GRO/GSO super-packet handling
I tested the series on top of net under virtme-ng (QEMU/KVM, x86_64). selftests/net/hsr/hsr_gro_superpacket.sh passes: the SAN emits TSO super-packets (TX frame-size average around 41 kB, well over the 2048 byte threshold) while both DUT LAN legs stay per-frame (average around 1497 bytes, under the 1514 byte guard), and the test reports success. For contrast, without the series the same topology leaks oversized, HSR-tagged frames onto the LAN legs (up to roughly 28 kB, ethertype 0x88fb), which this work eliminates. hsr_ping, prp_ping and hsr_redbox still pass. I also went through the code. Patch 1 mirrors netif_disable_lro() and dev_disable_lro() faithfully, and clearing both NETIF_F_GRO and NETIF_F_GRO_HW matches the changelog intent. For patch 2 I audited all seqnr_lock users; after the change it guards only the sequence counter updates, so dropping the outer lock around hsr_forward_skb() cannot race any other state. For patch 3 the __skb_gso_segment() dispatch and the consume_skb() and kfree_skb() paths look correct, and the port type gate keeps LAN and tagged aggregates out of software segmentation. Per-patch Reviewed-by for patches 1 to 3 sent separately. Tested-by: Ali Ahmet Memis <[email protected]>
