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

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: <20150310225042.GA14112@lunn.ch>
Date:	Tue, 10 Mar 2015 23:50:42 +0100
From:	Andrew Lunn <andrew@...n.ch>
To:	Mathieu Olivari <mathieu@...eaurora.org>
Cc:	netdev@...r.kernel.org, linux@...ck-us.net, jogo@...nwrt.org,
	f.fainelli@...il.com
Subject: Re: RFC: dsa: add support for multiple CPU ports

> > 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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html