netdev - Re: [patch net-next v2 8/9] switchdev: introduce Netlink API

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:	Sat, 20 Sep 2014 19:38:54 +0200
From:	Jiri Pirko <jiri@...nulli.us>
To:	Scott Feldman <sfeldma@...ulusnetworks.com>
Cc:	Roopa Prabhu <roopa@...ulusnetworks.com>,
	Jamal Hadi Salim <jhs@...atatu.com>,
	netdev <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Neil Horman <nhorman@...driver.com>,
	Andy Gospodarek <andy@...yhouse.net>,
	Thomas Graf <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>,
	Vlad Yasevich <vyasevic@...hat.com>,
	Cong Wang <xiyou.wangcong@...il.com>,
	John Fastabend <john.r.fastabend@...el.com>,
	Eric Dumazet <edumazet@...gle.com>,
	Florian Fainelli <f.fainelli@...il.com>,
	"John W. Linville" <linville@...driver.com>, dev@...nvswitch.org,
	jasowang@...hat.com, ebiederm@...ssion.com,
	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@...il.com,
	Neil.Jerram@...aswitch.com, ronye@...lanox.com,
	Simon Horman <simon.horman@...ronome.com>,
	Alexander H Duyck <alexander.h.duyck@...el.com>,
	Shrijeet Mukherjee <shm@...ulusnetworks.com>
Subject: Re: [patch net-next v2 8/9] switchdev: introduce Netlink API

Sat, Sep 20, 2014 at 07:21:10PM CEST, sfeldma@...ulusnetworks.com wrote:
>
>On Sep 20, 2014, at 5:51 AM, Roopa Prabhu <roopa@...ulusnetworks.com> wrote:
>
>> On 9/20/14, 1:10 AM, Scott Feldman wrote:
>>> On Sep 19, 2014, at 8:41 PM, Roopa Prabhu <roopa@...ulusnetworks.com>
>>>  wrote:
>>> 
>>> 
>>>> On 9/19/14, 8:49 AM, Jiri Pirko wrote:
>>>> 
>>>>> Fri, Sep 19, 2014 at 05:25:48PM CEST, jhs@...atatu.com
>>>>>  wrote:
>>>>> 
>>>>>> On 09/19/14 09:49, Jiri Pirko wrote:
>>>>>> 
>>>>>>> This patch exposes switchdev API using generic Netlink.
>>>>>>> Example userspace utility is here:
>>>>>>> 
>>>>>>> https://github.com/jpirko/switchdev
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> Is this just a temporary test tool? Otherwise i dont see reason
>>>>>> for its existence (or the API that it feeds on).
>>>>>> 
>>>>> Please read the conversation I had with Pravin and Jesse in v1 thread.
>>>>> Long story short they like to have the api separated from ovs datapath
>>>>> so ovs daemon can use it to directly communicate with driver. Also John
>>>>> Fastabend requested a way to work with driver flows without using ovs ->
>>>>> that was the original reason I created switchdev genl api.
>>>>> 
>>>>> Regarding the "sw" tool, yes it is for testing purposes now. ovs daemon
>>>>> will use directly switchdev genl api.
>>>>> 
>>>>> I hope I cleared this out.
>>>>> 
>>>> We already have all the needed rtnetlink kernel api and userspace tools around it to support all
>>>> switching asic features. ie, the rtnetlink api is the switchdev api. We can do l2, l3, acl's with it.
>>>> Its unclear to me why we need another new netlink api. Which will mean none of the existing tools to
>>>> create bridges etc will work on a switchdev.
>>>> Which seems like going in the direction exactly opposite to what we had discussed earlier.
>>>> 
>>> Existing rtnetlink isn’t available to swdev without some kind of snooping the echoes from the various kernel components (bridge, fib, etc).  With swdev_flow, as Jiri has defined it, there is an additional conversion needed to bridge the gap (bad expression, I know) between rtnetlink and swdev_flow.  This conversion happens in the kernel components.  For example, the bridge module, still driven from userspace by existing rtnetlink, will formulate the necessary swdev_flow insert/remove calls to the swdev driver such that HW will offload the fwd path.
>>> 
>>> You have:
>>>     user -> rtnetlink -> kernel -> netlink echo -> [some process] -> [some driver] -> HW
>>> 
>>> 
>>> Jiri has:
>>>     user -> rtnetlink -> kernel -> swdev_* -> swdev driver -> HW
>>> 
>>> 
>> Keeping the goal to not change or not add a new userspace API in mind,
>> I have :
>>     user -> rtnetlink -> kernel -> ndo_op -> swdev driver  -> HW
>> 
>
>Then you have the same as Jiri, for the traditional L2/L3 case.
>
>> Jiri has:
>>     user -> genl (newapi) -> kernel -> swdev_* -> swdev driver -> HW
>
>Jiri’s genl is for userspace apps that are talking rtnetlink, like OVS.  It’s not a substitute for rtnetlink, it’s an alternative.  The complete picture is:

Not an alternative, an addition.

>
>user -> swdev genl -----
>                        \
>                         \
>                          -------> kernel -> ndo_swdev_* -> swdev driver -> HW
>                         /
>                        /
>user -> rtnetlink ------

True is that, as Thomas pointed out, we can probably nest this into
rtnl_link messages. That might work.
--
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