Re: [patch net-next RFC 0/4] introduce infrastructure for support of switch chip datapath
From: tgraf <tgraf@suug.ch>
Date: 2014-03-25 21:40:00
On 03/25/14 at 01:00pm, Florian Fainelli wrote:
2014-03-25 12:40 GMT-07:00 Neil Horman [off-list ref]:quoted
On Tue, Mar 25, 2014 at 11:33:22AM -0700, Florian Fainelli wrote:quoted
2014-03-25 10:39 GMT-07:00 Neil Horman [off-list ref]:quoted
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.I think this would be a good model for simple embedded switches that only support 802.1q VLANs for instance, since we won't be able to get any actual data to be sent/received to any per-port netdevice, those per-port netdevices would only be effective for control at the L2 level. For switches that do support tags, I think we do want per-port netdevices to appear in the regular netdevices namespace as those might be able to get actual data sent to/received from by using these tags, at least momentarily until a higher-level entity decides otherwise (e.g: by bridging, disabling interfaces...).Well, perhaps thats the answer then - Augment the model to allow for the registration of net_devices to private lists within a switch device, but don't require it. If a given chip supports the assignment of L3 data by the cpu, the use of iptables etc, let the switch driver do so, its not like we can't do that already, but for the smaller devices, keeping them tightly controled via the switch driver in such a way that user space can only access them with permission from the switch driver. Does that seem reasonable?Sure that looks good, the switch driver will know what L2/L3 features it has, and the higher levels will know how to utilize that information to construct the net_devices stacking and namespacing.
I think all it takes is to correctly apply the existing separation which is already available but not applied right now. We already have the L2/L3 separation in place: net_device vs in_device/inet6_dev/.... A pure L2 device that will never do L3 on the CPU would only need to set a flag which we check before allocating a in_device and therefore prevent from all the L3 configs to be exposed.