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

[Lukasz Majewski <lukma@denx.de>]

[-- Attachment #1: Type: text/plain, Size: 2797 bytes --]

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@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]