2014-03-26 11:14 GMT-07:00 Jiri Pirko [off-list ref]:

Wed, Mar 26, 2014 at 06:58:32PM CET, f.fainelli@gmail.com wrote:

quoted

2014-03-26 10:35 GMT-07:00 Jiri Pirko [off-list ref]:

quoted

Wed, Mar 26, 2014 at 06:29:07PM CET, f.fainelli@gmail.com wrote:

quoted

2014-03-26 9:59 GMT-07:00 Jiri Pirko [off-list ref]:

quoted

Wed, Mar 26, 2014 at 05:54:17PM CET, roopa@cumulusnetworks.com wrote:

quoted

On 3/26/14, 3:54 AM, Jamal Hadi Salim wrote:

quoted

On 03/26/14 01:37, Roopa Prabhu wrote:

quoted

On 3/25/14, 1:11 PM, Florian Fainelli wrote:

quoted

2014-03-25 12:35 GMT-07:00 Neil Horman [off-list ref]:

quoted

Sorry about getting on this thread late and possibly in the middle.
Agree on the idea of keeping the ports linked to the master switch dev
(or the 'conduit' to the switch chip) via private list instead of the
master-slave relationship proposed earlier.
By private i mean the netdev->priv linkage to the master switch dev and
not really keeping the ports from being exposed to the user.

We think its better to keep the switch ports exposed as any other netdev
on linux.
 This approach will make the switch ports look exactly like a nic port
and all tools will continue to work seamlessly. The switch port
operations could internally be forwarded to the switch netdev (sw1 in
the above case).

example:
$ip link set dev sw1p0 up
$ethtool -S sw1p0

I like the approach. I know the above is a simple version, but i am
assuming you also mean i can do things like
ip route add ...
bridge fdb add ... (and if you like your brctl go ahead)
bonding ...

yes, exactly.  We support this model on our boxes today.
User can bond switch ports on our box in the exact same way as he/she
would bond two nic ports.
Our 'conduit to switch chip' reflects the corresponding lag
configuration in the switch chip.
Same goes for bridging, routing, acls.

So you implement bonding netlink api? Or you hook into bonding driver
itselt? Can you show us the code?

Before we start talking about bonding, maybe we should make sure that
we cover some basic hardware switches uses which are to make some
ports belong to certain VLANs, tagged or untagged?

It seems to me like this would become something like this, assuming P0
and P1 are two switch ports and 'eth0' is the CPU port, where P0 and
P1 belong to VLAN1 and CPU belongs to VLAN2:

ip link set dev sw1p0 up
ip link set dev sw1p1 up
ip link set dev eth0 up

I might be mistaken, But I think you are missing a switch port
representing a connection to eth0 (eth0 being cpu conterpart of it).
Or is it one of sw1p0 and sw1p1 ?

You are right, sw1p0 and sw1p1 were meant to be, say LAN ports in my example.

I think there is an implicit convention that sw1 represents the
Ethernet switch port connected to the CPU Ethernet MAC, and that it is
always connected, hence there is no need to create a "fake" bridge to
link sw1 to eth0 for instance?

I think you are kind of mixing apples and oranges (or I might be I'm not
understanding you correctly).
This is how I see it, sticking to the names you use in the example:

            (sw1) (abstract place-holder netdev)
          --------
         switch chip                   CPU
   -----------------------            ------
   sw1p0 sw1p1 sw1p2 sw1p3             eth0
     |     |     |     |                |
    PHY   PHY   PHY    ------someMII-----

You see that eth0 is the CPU part of the "connection" and sw1p3 is the
switch part (port representation).

Thanks for clarifying, this is indeed how it should be modelled/represented.
-- 
Florian