netdev - Re: Crosschip bridge functionality

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]

Date:   Fri, 23 Dec 2022 14:36:59 -0800
From:   Colin Foster <colin.foster@...advantage.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Vladimir Oltean <olteanv@...il.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        netdev@...r.kernel.org
Subject: Re: Crosschip bridge functionality

On Fri, Dec 23, 2022 at 10:18:54PM +0100, Andrew Lunn wrote:
> > > > What's the catch?
> > > 
> > > I actually think you need silicon support for this. Earlier versions
> > > of the Marvell Switches are missing some functionality, which results
> > > in VLANs leaking in distributed setups. I think the switches also
> > > share information between themselves, over the DSA ports, i.e. the
> > > ports between switches.
> > > 
> > > I've no idea if you can replicate the Marvell DSA concept with VLANs.
> > > The Marvell header has D in DSA as a core concept. The SoC can request
> > > a frame is sent out a specific port of a specific switch. And each
> > > switch has a routing table which indicates what egress port to use to
> > > go towards a specific switch. Frames received at the SoC indicate both
> > > the ingress port and the ingress switch, etc.
> > 
> > "It might not work at all" is definitely a catch :-)
> > 
> > I haven't looked into the Marvell documentation about this, so maybe
> > that's where I should go next. It seems Ocelot chips support
> > double-tagging, which would lend itself to the SoC being able to
> > determine which port and switch for ingress and egress... though that
> > might imply it could only work with DSA ports on the first chip, which
> > would be an understandable limitation.
> > 
> > > 
> > > > In the Marvell case, is there any gotcha where "under these scenarios,
> > > > the controlling CPU needs to process packets at line rate"?
> > > 
> > > None that i know of. But i'm sure Marvell put a reasonable amount of
> > > thought into how to make a distributed switch. There is at least one
> > > patent covering the concept. It could be that a VLAN based
> > > re-implemention could have such problems. 
> > 
> > I'm starting to understand why there's only one user of
> > crosschip_bridge_* functions. So this sounds to me like a "don't go down
> > this path - you're in for trouble" scenario.
> 
> What is your real use case here?

Fair question. We have a baseboard configuration with cards that offer
customization / expansion. An example might be a card that offers
additional fibre / copper ports, which would lend itself very nicely to
a DSA configuration... more cards == more ports.

We can see some interesting use of vlans for all sorts of things. I
haven't been the boots on the ground, so I don't know all the use-cases.
My main hope is to be able to offer as much configurability for the
system integrators as possible. Maybe sw2p2 is a tap of sw1p2, while
sw2p3, sw2p4, and sw1p3 are bridged, with the CPU doing IGMP snooping
and running RSTP.

> 
> I know people have stacked switches before, and just operated them as
> stacked switches. So you need to configure each switch independently.
> What Marvell DSA does is make it transparent, so to some extent it
> looks like one big switch, not a collection of switches.

That is definitely possible. It might make the people doing any system
integration have a lot more knowledge than a simple "add this port to
that bridge". My goal is to make their lives as easy as can be.

It sounds like that all exists with Marvell hardware...