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

[Fernando Fernandez Mancera]

On Mon, 06 Jul 2026 13:41:27 +0000, Xin Xie <xiexinet@xxxxxxxxx> 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!