Re: RFC: dsa: add support for multiple CPU ports

[Andrew Lunn <andrew@lunn.ch>]

> > I had a different solution in mind for multiple CPU ports. I've no
> > idea if it actually works though, i've not had time to investigate.
> > It would actually put the host CPU ports into a switch trunk, and use
> > team/bond driver on the host. You then get one logical 2Gbp link to
> > the switch and run DSA over that.
> > 
> 
> I could see it working on the Tx path - as the destination port is specified
> in the header -, but on the Rx path, how would the switch figure out which
> CPU port it should send the packet to?
>
> These switches doesn't have a concept of bonding, so this decision is generally
> based on the internal ARL table, and is automatically learnt by looking at the
> src MAC@ of the incoming packets.

All Marvell switches, and according to Florian SF2 and B53 support
trunk groups. I assume the switch does load balancing between ports in
a trunk. On the CPU you can then use the header to determine which
port the packet came from.

> When using bonding, the switch would see both eth0 & eth1 MAC@ on both of
> its CPU ports. The destination CPU port would be unexpected at best; I could
> see some switches being able to support this, but most of them would not.

At the moment, this is purely an idea. I do have two boards where i
can test it out with Marvell devices, once i get some spare time.
Florian might be able to comment about SF2 and B53, if we thinks
trunking and broadcom tags can be combined.

> At the very least, we would need to treat "dsa,ethernet" as an array,
> and specify the list of ethernet device node that connects to the switch.

True.

> I still think putting this information in the port section makes sense,
> as it represents the board layout more accurately than having a global
> node at a dsa level.

Yes, it does make sense to have it in port. But to keep backwards
compatibility, we need at keep dsa,ethernet, with at least one
interface.

	Andrew