On 03/25/14 15:35, Neil Horman wrote:

On Tue, Mar 25, 2014 at 06:00:09PM +0000, Thomas Graf wrote:

quoted

How about a new device flag indicating pure L2 mode? Any L3 address
configuration would fail with EAFNOSUPP.

Yeah, we've discussed that before, and it seems like a good idea, though I'm not
sure that its flexible enough.  It clearly prevents L3 operations on devices
that can only do L2, which is great, but that may not be sufficient for some
devices.  For example, what if you wanted to use ebtables on an L2 port where
the hardware can't mirror the actions of a given table rule?  Do we need to
expand out those capabilities?

There are two capability approaches.
a) you do things and let the kernel reject
b) You discover the capabilities and do something more interesting.
We already do this kind of stuff in user tools today (simple example
is name->ifindex mapping querying).

What is missing is ability to store richer capabilities which are not
just boolean in nature.

Maybe I'm not being clear. I'm not suggesting that we abandon the use of a
net_device to do any of this work, only that we add a layer of indirection to
get to it.  By Augmenting the existing network device stack to allow
registration of net_devices to arbitrary lists, rather than to a fixes
per-net-namespace global device list, we can operate net_devices that are only
visible within the scope of a given switch fabric.  User space still works the
same way, it just requires the specification of additional information when
speaking to ports on a switch device that may not be directly accessible via the
cpu.  For example, if a systems has a directly connected nic (em1), and a switch
fabric with a master bridge port (sw1), and 10 external ports (sw1pX), we could
access them all from user space via ip link show.  for example:

1) ip link show:
em1
sw1

2) ip link show sw1
sw1

3) ip link show -p sw1
sw1p0
sw1p1
sw1p2...


The idea is to augment user space to allow the visibiliy of ports through the
switch device, not directly, but using the same existing mechanisms.  We can
reuse all the existing infrastruture, but with this model, control must pass
through the switch device driver, allowing it to taylor available features by
passing the netlink request on to the appropriate netdevice, or sending back an
error itself.

I think i am with you mostly - just not on the visibility of a "master"
device.
Expose the ports. Users create bridges bonds and if the hardware is
capable it does the hard work to ensure consistency. No change in tools.

cheers,
jamal