Re: [patch net-next RFC 0/4] introduce infrastructure for support of switch chip datapath

[Thomas Graf <tgraf@suug.ch>]

On 03/25/14 at 01:39pm, Neil Horman wrote:
> No, but it would be really nice if these smaller devices could take advantage of
> this infrastructure.  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.
> 
> 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.

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

> 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 believe this would defeat the main advantage of reusing net_device
model which is compatibility with the well established standard toolset.

In an ideal world, we represent what is possible using the existing
net_device model.

On top of that, like for VFs, we provide extended nested attributes or
alternate control paths such as via OVS that provide the additional
flexibility and control required by the more advanced devices.