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 > If a non-ovs flow interface is needed from userspace, we can extend the > existing interface to include flows. > I don't understand why we should replace the existing rtnetlink switchdev api > to accommodate flows. > > Thanks, > Roopa > -scott _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
