Date:	Tue, 25 Mar 2014 13:00:16 -0700
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Neil Horman <nhorman@...driver.com>
Cc:	Jamal Hadi Salim <jhs@...atatu.com>, Jiri Pirko <jiri@...nulli.us>,
	netdev <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>, andy <andy@...yhouse.net>,
	tgraf <tgraf@...g.ch>, dborkman <dborkman@...hat.com>,
	ogerlitz <ogerlitz@...lanox.com>, jesse <jesse@...ira.com>,
	pshelar <pshelar@...ira.com>, azhou <azhou@...ira.com>,
	Ben Hutchings <ben@...adent.org.uk>,
	Stephen Hemminger <stephen@...workplumber.org>,
	jeffrey.t.kirsher@...el.com, vyasevic <vyasevic@...hat.com>,
	Cong Wang <xiyou.wangcong@...il.com>,
	John Fastabend <john.r.fastabend@...el.com>,
	Eric Dumazet <edumazet@...gle.com>,
	Scott Feldman <sfeldma@...ulusnetworks.com>,
	Lennert Buytenhek <buytenh@...tstofly.org>,
	Felix Fietkau <nbd@...nwrt.org>
Subject: Re: [patch net-next RFC 0/4] introduce infrastructure for support of
 switch chip datapath

2014-03-25 12:40 GMT-07:00 Neil Horman <nhorman@...driver.com>:
> On Tue, Mar 25, 2014 at 11:33:22AM -0700, Florian Fainelli wrote:
>> 2014-03-25 10:39 GMT-07:00 Neil Horman <nhorman@...driver.com>:
>> > On Mon, Mar 24, 2014 at 07:07:35PM -0400, Jamal Hadi Salim wrote:
>> >> On 03/22/14 05:48, Jiri Pirko wrote:
>> >> >Fri, Mar 21, 2014 at 01:04:20PM CET, jhs@...atatu.com wrote:
>> >>
>> >> >Hmm. This got me thinking about netdev and switches well and perhaps the
>> >> >switchdev api could be mostly implemented by couple of more ndos and
>> >> >feature flags. That way we could stick to your immortal netdev :)
>> >> >
>> >> >
>> >>
>> >> Perhaps ;->
>> >>
>> >> >>
>> >> >>In my view: that (immortal) device for L2/bridging is the bridge or
>> >> >>maybe a more barebone version of the bridge (since it has gained a
>> >> >>little more weight in recent times).
>> >> >
>> >> >Well, I do not think that bridge is ideal abstraction for modern switch
>> >> >chips. Bridge is very limited.
>> >> >
>> >>
>> >> True - but i was more thinking of being inclusive of the smaller
>> >> devices. They are mostly L2 only and in very limited scope. And thats
>> >> probably 95% of the population. The things you are talking about
>> >> are very high end and they can do more. Florian's taxanomy was useful.
>> >>
>> >> >But I don't necessary think it is needed to "mask" as a bride or mimic a
>> >> >bridge in any way. DSA does not do that either.
>> > 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.
>>
>> In fact, some switches could have valid L3 configurations, what you
>> usually do is have the switch be configured such that it selectively
>> inserts Broadcom tags for a given set of physical ports, such that
>> your CPU port (In-band Management port in Broadcom terminology), gets
>> flooded with such packets, and can dispatch those packets to the
>> per-port netdevices. Then you can take any decisions based on those
>> received packets, such as bridging this per-port netdevice with
>> another one for instance, or any switch topology change.
>>
>> >
>> > 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.
>>
>> 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.
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists