Message-ID: <Y6YtiwqJWyv3yW9r@euler>
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...

Powered by blists - more mailing lists