Thread (125 messages) 125 messages, 14 authors, 2014-04-02

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help