On 2026-07-16 14:00 +0200, Fernando Fernandez Mancera wrote: > On Mon, 06 Jul 2026 13:41:27 +0000, Xin Xie <[email protected]> wrote: > > This series adds PRP RedBox support to the hsr driver: a PRP node that > > proxies one or more SANs sitting behind an interlink port (IEC 62439-3, > > PRP-SAN). HSR-SAN has been supported since commit 5055cccfc2d1 ("net: hsr: > > Provide RedBox support (HSR-SAN)"); this extends the equivalent capability > > to PRP, reusing the existing protocol-neutral proxy machinery > > (proxy_node_db, hsr_proxy_announce(), hsr_prune_proxy_nodes()). > > > > A SAN behind the interlink does bidirectional unicast with peers on the PRP > > network, its source MAC is preserved on the wire, the PRP RCT is correct, > > and the RedBox announces each proxied SAN with the RedBox-MAC TLV (Type 30) > > in its supervision frames. > > > > The series is bisect-safe: the datapath, duplicate discard and supervision > > support are added first; the rtnetlink rejection of "type hsr ... interlink > > <dev> proto 1" is removed only in patch 3, once the feature is complete. > > > > Design notes: > > > > - prp_drop_frame() does not walk the node tables. The destination > > classification (PRP-network node vs proxied SAN) is resolved once per > > frame in fill_frame_info() and cached in struct hsr_frame_info, so the > > per egress-port drop decision is O(1) in the softIRQ path. The > > classification is gated on PRP RedBox devices (prot_version == PRP_V1 && > > hsr->redbox), so HSR RedBox traffic is not affected. > > > > - The LAN A/B duplicate test is factored into prp_is_lan_dup() so the new > > PRP interlink rules in prp_drop_frame() do not change hsr_drop_frame() > > behaviour, including the NETIF_F_HW_HSR_FWD path. This is software PRP > > RedBox only; it adds no new hardware-offload contract. > > > > - The supervision emitter uses pre-reserved tailroom (hsr_init_skb() + > > skb_put()) on the existing GFP_ATOMIC path; no skb_linearize() or > > pskb_expand_head(). The RedBox-MAC TLV is followed by an explicit EOT > > (Type 0, Length 0); padding via skb_put_padto(ETH_ZLEN) and the 6-byte > > PRP RCT remain at the absolute tail of the egress frame. > > > > - The hsr_get_node() hsr_ethhdr length guard is relaxed only for PRP > > supervision frames (prot_version == PRP_V1 && ETH_P_PRP && is_sup), which > > are untagged with mac_len == ETH_HLEN. HSR (ETH_P_HSR) supervision is > > front-tagged and keeps the original length requirement, so HSR > > malformed-frame filtering is unchanged. > > > > Testing (on a net-next v7.2-rc1 kernel built from this base, x86-64): > > - checkpatch.pl --strict: patches 1-3 clean; patch 4 reports only the > > expected "added file(s), does MAINTAINERS need updating?" note, which is > > ignorable here -- MAINTAINERS already lists > > tools/testing/selftests/net/hsr/ under HSR NETWORK PROTOCOL. > > - git diff --check clean; the series git-am's onto the base commit. > > - tools/testing/selftests/net/hsr/hsr_prp_redbox.sh: PASS on the patched > > kernel (bidirectional unicast, SAN MAC preservation, RedBox-MAC TLV + > > EOT in the proxy-announce). > > - HSR regression on the same kernel: hsr_redbox.sh (HSR-SAN/RedBox), > > hsr_ping.sh and prp_ping.sh all PASS, confirming the PRP changes do not > > regress the existing HSR/PRP paths. > > - netns checks: peer<->SAN 0% loss with no duplicates and a valid PRP RCT > > on the wire; a silent SAN is pruned from the announce; zero driver > > WARN/BUG/Oops/RCU-stall during the run. > > > > Beyond the in-tree selftest, this exact series (applied to this base and > > running as the net-next kernel on x86-64 hardware) was also validated with > > an > > out-of-tree IEC 62439-3 conformance harness (supervision TLV chain, > > duplicate > > discard, cross-LAN rejection, seqnr rollover, VLAN/multicast/GOOSE frame > > types > > with the RCT verified at the absolute frame tail), and > > interoperability-tested > > against a commercial PRP RedBox (Siemens SCALANCE X204RNA) over 100 Mbit/s > > Fast Ethernet with NIC hardware (PTP) timestamping: a mid-stream single-LAN > > outage of ~2 s at 10 kpps was bridged with zero lost and zero duplicate > > frames > > (seamless PRP failover), and the duplicate-discard window held zero lost / > > zero duplicates under netem asymmetric delay up to 100 ms (~1000 sequence > > numbers in flight), 25% reorder, and 5% single-LAN loss. The failover and > > impairment matrix was additionally repeated on a KASAN + lockdep + kmemleak > > instrumented build of this kernel, including a 72-carrier-event link > > flap-storm with deliberate double-LAN cuts: zero KASAN, lockdep, or kmemleak > > findings. This out-of-tree testing is supplementary and not required to > > evaluate the series. > > > > The series looks good to me, I just found a couple of nits. > > Thank you!
Oh I just realized you posted a v3 - anyway, as there were no changes my comments also apply there. Thanks, Fernando.
