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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140326072426.GC2869@minipsycho.orion>
Date:	Wed, 26 Mar 2014 08:24:26 +0100
From:	Jiri Pirko <jiri@...nulli.us>
To:	Neil Horman <nhorman@...driver.com>
Cc:	Jamal Hadi Salim <jhs@...atatu.com>,
	Florian Fainelli <f.fainelli@...il.com>,
	netdev <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>, andy@...yhouse.net,
	tgraf@...g.ch, dborkman@...hat.com, ogerlitz@...lanox.com,
	jesse@...ira.com, pshelar@...ira.com, 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>
Subject: Re: [patch net-next RFC 0/4] introduce infrastructure for support of
 switch chip datapath

Tue, Mar 25, 2014 at 06:39:27PM CET, nhorman@...driver.com wrote:
>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.
>
>Would it be worth considering a private interface model?  That is to say:

I'm personaly strongly againts this. All netdevices should stay under net
namespace list. If you break this, I expect many unexpected issues.
+ There is not really a reason for this breakage.


>
>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
>
--
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