From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neil Horman Subject: Re: [patch net-next RFC 0/4] introduce infrastructure for support of switch chip datapath Date: Tue, 25 Mar 2014 13:39:27 -0400 Message-ID: <20140325173927.GE8102@hmsreliant.think-freely.org> References: <1395243232-32630-1-git-send-email-jiri@resnulli.us> <532AD5B3.6020205@mojatatu.com> <20140320124021.GA2946@minipsycho.orion> <532C2AC4.7080303@mojatatu.com> <20140322094852.GB2844@minipsycho.orion> <5330BAB7.3040501@mojatatu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jiri Pirko , Florian Fainelli , netdev , David Miller , andy@greyhouse.net, tgraf@suug.ch, dborkman@redhat.com, ogerlitz@mellanox.com, jesse@nicira.com, pshelar@nicira.com, azhou@nicira.com, Ben Hutchings , Stephen Hemminger , jeffrey.t.kirsher@intel.com, vyasevic , Cong Wang , John Fastabend , Eric Dumazet , Scott Feldman , Lennert Buytenhek To: Jamal Hadi Salim Return-path: Received: from charlotte.tuxdriver.com ([70.61.120.58]:57743 "EHLO smtp.tuxdriver.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755266AbaCYRkH (ORCPT ); Tue, 25 Mar 2014 13:40:07 -0400 Content-Disposition: inline In-Reply-To: <5330BAB7.3040501@mojatatu.com> Sender: netdev-owner@vger.kernel.org List-ID: 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@mojatatu.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. 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. Best Neil