On 9/20/14, 1:09 AM, Jiri Pirko wrote:
Sat, Sep 20, 2014 at 05:41:16AM CEST, 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.
No one is proposing such API. Note that what I'm trying to solve in my
patchset is FLOW world. There is only one API there, ovs genl. But the
usage of that for hw offload purposes was nacked by ovs maintainer. Plus
couple of people wanted to run the offloading independently on ovs
instance. Therefore I introduced the switchdev genl, which takes care of
that. No plan to extend it for other things you mentioned, just flows.
ok, That was not clear to me. Introducing a new genl api and calling it the
switchd dev api can result it non-flow creep into it in the future.
Which seems like going in the direction exactly opposite to what we had
discussed earlier.
Nope. The previous discussion ignored flows.
If a non-ovs flow interface is needed from userspace, we can extend the
existing interface to include flows.
How? You mean to extend rtnetlink? What advantage it would bring
comparing to separate genl iface?
yes. Advantage would be that we dont have yet another parallel switchdev
netlink api.
I don't understand why we should replace the existing rtnetlink switchdev api
to accommodate flows.
Sorry, I do not undertand what "existing rtnetlink switchdev api" you
have on mind. Would you care to explain?
I am taking about existing rtnetlink api that bridge, ip link uses to
talk l2 and l3 to the kernel.
RTM_NEWROUTE etc.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
