On 03/25/14 13:39, Neil Horman wrote:

No, but it would be really nice if these smaller devices could take advantage of
this infrastructure.

Indeed.

Looking at it, I don't see why thats not possible.  The
big trick (as we've discussed in the past), is using a net_device structure to
take advantage of all the features that net_devices offer while not enabling the
device specific features that some hardware doesn't allow.

Exactly. And i dont think thats hard to do. I do think for capabilities,
netdev->features is insufficient (example I cant export to user space
the size of my h/w fdb table etc). But those things can be easily
ironed out.

For instance the broadcom chips that live in many wireless routers would be well
served by the model jiri has here as far as Media level interface control is
concerned (i.e. ifup/down/speed/duplex/etc), but its a bit lacking in that
net_devices are assumed to support L3 protocol configuration (i.e. they can have
ip addresses assigned to them), which you can't IIRC do on these chips.

This is part of the challenge i was talking about and why the lowest
common denominator is just ports and L2 bridging.

Would it be worth considering a private interface model?  That is to say:

1) Ports on a switch chip are accessed using net_device structures, but
registered to a private list contained within the switch device, rather than to
the net namespaces device list.

2) Access to the switch ports via user space is done through the master switch
interface with additional netlink attributes specifying the port on the switch
to access (or not to access the master switch device directly)


Such a model I think might fit well with Jiri's code here and provide greater
flexibility for a wider range of devices.  It would of course require
augmentation for user space, but the changes would be additive, so I think they
would be reasonable.  This would also allow the switch device to have a hook in
the control path to block or allow features that the hardware may or may not
support while still being able to use the existing net_device infrastructure to
support these operations as they are normally carried out.

I think Jiri's model is upside down (Yes, I was on that boat as well
earlier)
What needs to be exposed are ports. Something like #1 above which is not
a netdev but rather the conduit to the chip.
Note: We already an above working model with bridging today. If i attach
a port to a bridge I can infact get/set the fdb entries from/to the 
bridge as well as ones offloaded on the chip/hware.
I should be able to do the same with stats etc.
Seems to make sense we to extend it to other features.
The litmus test is: Can i have my iproute2 please? If you can do that
then you are allowing me to do bridges, routes, ports, vxlan, tunnels
qos etc. Whatever the chips  capabilities allow for otherwise I am
terminating at the CPU level.

cheers,
jamal