Re: [PATCH net-next v2 0/4] net: hsr: PRP RedBox (PRP-SAN) support

[Fernando Fernandez Mancera <fmancera@suse.de>]

On 2026-07-16 14:00 +0200, Fernando Fernandez Mancera wrote:
> On Mon, 06 Jul 2026 13:41:27 +0000, Xin Xie <xiexinet@gmail.com> 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.