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

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.

Thanks,
Roopa