On 9/20/14, 1:10 AM, Scott Feldman wrote:
On Sep 19, 2014, at 8:41 PM, Roopa Prabhu [off-list ref] wrote:
quoted
On 9/19/14, 8:49 AM, Jiri Pirko wrote:
quoted
Fri, Sep 19, 2014 at 05:25:48PM CEST, jhs-jkUAjuhPggJWk0Htik3J/w@public.gmane.org wrote:
quoted
On 09/19/14 09:49, Jiri Pirko wrote:
quoted
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
Jiri has:
user -> genl (newapi) -> kernel -> swdev_* -> swdev driver -> HW
On Sep 20, 2014, at 5:51 AM, Roopa Prabhu [off-list ref] wrote:
On 9/20/14, 1:10 AM, Scott Feldman wrote:
quoted
On Sep 19, 2014, at 8:41 PM, Roopa Prabhu [off-list ref]
wrote:
quoted
On 9/19/14, 8:49 AM, Jiri Pirko wrote:
quoted
Fri, Sep 19, 2014 at 05:25:48PM CEST, jhs@mojatatu.com
wrote:
quoted
On 09/19/14 09:49, Jiri Pirko wrote:
quoted
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:
user -> swdev genl -----
\
\
-------> kernel -> ndo_swdev_* -> swdev driver -> HW
/
/
user -> rtnetlink ------
-scott
Sat, Sep 20, 2014 at 07:21:10PM CEST, sfeldma@cumulusnetworks.com wrote:
On Sep 20, 2014, at 5:51 AM, Roopa Prabhu [off-list ref] wrote:
quoted
On 9/20/14, 1:10 AM, Scott Feldman wrote:
quoted
On Sep 19, 2014, at 8:41 PM, Roopa Prabhu [off-list ref]
wrote:
quoted
On 9/19/14, 8:49 AM, Jiri Pirko wrote:
quoted
Fri, Sep 19, 2014 at 05:25:48PM CEST, jhs@mojatatu.com
wrote:
quoted
On 09/19/14 09:49, Jiri Pirko wrote:
quoted
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.
quoted
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.
On 9/20/14, 10:38 AM, Jiri Pirko wrote:
Sat, Sep 20, 2014 at 07:21:10PM CEST, sfeldma@cumulusnetworks.com wrote:
quoted
On Sep 20, 2014, at 5:51 AM, Roopa Prabhu [off-list ref] wrote:
quoted
On 9/20/14, 1:10 AM, Scott Feldman wrote:
quoted
On Sep 19, 2014, at 8:41 PM, Roopa Prabhu [off-list ref]
wrote:
quoted
On 9/19/14, 8:49 AM, Jiri Pirko wrote:
quoted
Fri, Sep 19, 2014 at 05:25:48PM CEST, jhs@mojatatu.com
wrote:
quoted
On 09/19/14 09:49, Jiri Pirko wrote:
quoted
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.
quoted
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.
quoted
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.