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

From: Roopa Prabhu <[email-masked]>
Date: Sat, 20 Sep 2014 18:30:33 -0700

On 9/20/14, 10:38 AM, Jiri Pirko wrote:
> Sat, Sep 20, 2014 at 07:21:10PM CEST, [email-masked] wrote:
>> On Sep 20, 2014, at 5:51 AM, Roopa Prabhu <[email-masked]> wrote:
>>
>>> On 9/20/14, 1:10 AM, Scott Feldman wrote:
>>>> On Sep 19, 2014, at 8:41 PM, Roopa Prabhu <[email-masked]>
>>>>   wrote:
>>>>
>>>>
>>>>> On 9/19/14, 8:49 AM, Jiri Pirko wrote:
>>>>>
>>>>>> Fri, Sep 19, 2014 at 05:25:48PM CEST, [email-masked]
>>>>>>   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.
That's the thing i was hinting as well. You can extend the existing 
infrastructure/api  instead of adding a new one.