netdev - Re: [net][hsr] Question regarding HSR RedBox functionality implementation (preferably on KSZ9477)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240109150414.6a402fec@wsk>
Date: Tue, 9 Jan 2024 15:04:14 +0100
From: Lukasz Majewski <lukma@...x.de>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>, Tristram.Ha@...rochip.com, Oleksij Rempel
 <o.rempel@...gutronix.de>, UNGLinuxDriver@...rochip.com,
 netdev@...r.kernel.org, Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
 George McCollister <george.mccollister@...il.com>
Subject: Re: [net][hsr] Question regarding HSR RedBox functionality
 implementation (preferably on KSZ9477)

Hi Vladimir,

> Hi Lukasz,
> 
> On Tue, Jan 09, 2024 at 01:32:34PM +0100, Lukasz Majewski wrote:
> > However, I'm wondering how the mainline Linux kernel could handle
> > HSR RedBox functionality (on document [1], Figure 2. we do have
> > "bridge" - OSI L2).
> > 
> > To be more interesting - br0 can be created between hsr0 and e.g.
> > lan3. But as expected communication breaks on both directions (to
> > SAN and to HSR ring).  
> 
> Yes, I suppose this is how a RedBox should be modeled. In principle
> it's identical to how bridging with LAG ports (bond, team) works -
> either in software or offloaded. 
> The trouble is that the HSR driver
> seems to only work with the DANH/DANP roles (as also mentioned in
> Documentation/networking/dsa/dsa.rst). I don't remember what doesn't
> work (or if I ever knew at all).

In the newest net-next only PRP_TLV_REDBOX_MAC is defined, which seems
to be REDBOX for DAN P (PRP).

> It might be the address substitution
> from hsr_xmit() that masks the MAC address of the SAN side device?
> 

This needs to be further investigated.

> > Is there a similar functionality already present in the Linux kernel
> > (so this approach could be reused)?
> > 
> > My (very rough idea) would be to extend KSZ9477 bridge join
> > functions to check if HSR capable interface is "bridged" and then
> > handle frames in a special way.
> > 
> > However, I would like to first ask for as much input as possible -
> > to avoid any unnecessary work.  
> 
> First I'd figure out why the software data path isn't working, and if
> it can be fixed. 

+1

> Then, fix that if possible, and add a new selftest to
> tools/testing/selftests/net/forwarding/, that should pass using veth
> interfaces as lower ports.
> 
> Then, offloading something that has a clear model in software should
> be relatively easy, though you might need to add some logic to DSA.
> This is one place that needs to be edited, there may be others.
> 
> 	/* dsa_port_pre_hsr_leave is not yet necessary since hsr
> devices cannot
> 	 * meaningfully placed under a bridge yet
> 	 */
> 

Ok, the LAG approach in /net/dsa/user.c can be used as an example.

Thanks for shedding some light on this issue :-)

> > 
> > Thanks in advance for help :-)
> > 
> > Link:
> > 
> > [1] -
> > https://ww1.microchip.com/downloads/en/Appnotes/AN3474-KSZ9477-High-Availability-Seamless-Redundancy-Application-Note-00003474A.pdf
> > 
> > 
> > Best regards,
> > 
> > Lukasz Majewski  




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@...x.de

Content of type "application/pgp-signature" skipped