netdev - Re: [patch net-next RFC 03/12] net: introduce generic switch devices support

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]

Date:	Fri, 22 Aug 2014 16:12:27 -0700
From:	Scott Feldman <sfeldma@...ulusnetworks.com>
To:	John Fastabend <john.fastabend@...il.com>
Cc:	Jiri Pirko <jiri@...nulli.us>, Jamal Hadi Salim <jhs@...atatu.com>,
	Florian Fainelli <f.fainelli@...il.com>,
	netdev <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Neil Horman <nhorman@...driver.com>,
	Andy Gospodarek <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>,
	Jeff Kirsher <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>,
	Roopa Prabhu <roopa@...ulusnetworks.com>,
	John Linville <linville@...driver.com>,
	dev <dev@...nvswitch.org>,
	"jasowang@...hat.com" <jasowang@...hat.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Nicolas Dichtel <nicolas.dichtel@...nd.com>,
	Sergey Ryazanov <ryazanov.s.a@...il.com>,
	Lennert Buytenhek <buytenh@...tstofly.org>,
	Aviad Raveh <aviadr@...lanox.com>,
	Felix Fietkau <nbd@...nwrt.org>,
	Alexei Starovoitov <alexei.starovoitov@...il.com>,
	Neil Jerram <Neil.Jerram@...aswitch.com>, ronye@...lanox.com
Subject: Re: [patch net-next RFC 03/12] net: introduce generic switch devices support


On Aug 22, 2014, at 12:14 PM, John Fastabend <john.fastabend@...il.com> wrote:

> On 08/22/2014 05:56 AM, Jiri Pirko wrote:
>> Fri, Aug 22, 2014 at 02:42:04PM CEST, jhs@...atatu.com wrote:
>>> On 08/21/14 13:05, Florian Fainelli wrote:
>>>> 2014-08-21 9:18 GMT-07:00 Jiri Pirko <jiri@...nulli.us>:
>>>>> The goal of this is to provide a possibility to suport various switch
>>>>> chips. Drivers should implement relevant ndos to do so. Now there is a
>>>>> couple of ndos defines:
>>>>> - for getting physical switch id is in place.
>>>>> - for work with flows.
>>>>> 
>>>>> Note that user can use random port netdevice to access the switch.
>>>> 
>>>> I read through this patch set, and I still think that DSA is the
>>>> generic switch infrastructure we already have because it does provide
>>>> the following:
>>>> 
>>>> - taking a generic platform data structure (C struct or Device Tree),
>>>> validate, parse it and map it to internal kernel structures
>>>> - instantiate per-port network devices based on the configuration data provided
>>>> - delegate netdev_ops to the switch driver and/or the CPU NIC when relevant
>>>> - provide support for hooking RX and TX traffic coming from the CPU NIC
>>>> 
>>>> I would rather we build on the existing DSA infrastructure and add the
>>>> flow-related netdev_ops rather than having the two remain in
>>>> disconnect while flow-oriented switches driver get progressively
>>>> added. I guess I should take a closer look at the rocker driver to see
>>>> how hard would that be for you.
>>>> 
>>>> What do you think?
>>> 
>>> 
>>> I thought we had concluded that DSA was a good path forward?  Or maybe at
>>> this stage we need to have several alternative approaches
>>> and we eventually converge?
>> 
>> That is true. I'm still unsure how to fit this on to DSA or how to change DSA
>> the way this fits. This is my quest now. Will report back in a week or so.
>> 
> 
> I would like to use the flow ops in some of our NICs that have
> a limited flow table in hardware. It might be easier to use the
> NICs as the first implementers of the API even though they are
> usually not as capable or large as flow tables in some of the
> larger switch asics.
> 
> In my opinion it can replace the ioctl flow director APIs although
> I don't like how it is tied to OVS in the some of the later RFC patches
> but we can work on that.

I think parallel efforts to get flow ops working on a real NIC with limited capabilities as well our fake enterprise-class rocker switch with full capabilities will really help solidify the swdev API.  Maybe even someone in the background that has access to a real enterprise switch can play along ;).  I hope you’re convinced from my other reply that the intent of swdev is to be independent of OVS.  If the implementation in the RFC doesn’t match the intent, we should fix it.  The elements of the swdev API we need convergence on are:

	- ndo_swdev_* ops to identify switch port and add/del flow match/action
	- struct sw_flow as generic flow match/action description
	- port netdevs to represent physical device ports

And maybe:

	- new device class to represent the switch itself
	- capabilities to express HW capabilities (limits, constraints, etc)


-scott



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