Sat, Sep 20, 2014 at 07:21:10PM CEST, sfel...@cumulusnetworks.com wrote: > >On Sep 20, 2014, at 5:51 AM, Roopa Prabhu <ro...@cumulusnetworks.com> wrote: > >> On 9/20/14, 1:10 AM, Scott Feldman wrote: >>> On Sep 19, 2014, at 8:41 PM, Roopa Prabhu <ro...@cumulusnetworks.com> >>> wrote: >>> >>> >>>> On 9/19/14, 8:49 AM, Jiri Pirko wrote: >>>> >>>>> Fri, Sep 19, 2014 at 05:25:48PM CEST, j...@mojatatu.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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
