[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <541CAA3C.5080105@intel.com>
Date: Fri, 19 Sep 2014 15:12:12 -0700
From: John Fastabend <john.r.fastabend@...el.com>
To: Jamal Hadi Salim <jhs@...atatu.com>, Jiri Pirko <jiri@...nulli.us>
CC: netdev@...r.kernel.org, davem@...emloft.net, nhorman@...driver.com,
andy@...yhouse.net, tgraf@...g.ch, dborkman@...hat.com,
ogerlitz@...lanox.com, jesse@...ira.com, pshelar@...ira.com,
azhou@...ira.com, ben@...adent.org.uk, stephen@...workplumber.org,
jeffrey.t.kirsher@...el.com, vyasevic@...hat.com,
xiyou.wangcong@...il.com, edumazet@...gle.com,
sfeldma@...ulusnetworks.com, f.fainelli@...il.com,
roopa@...ulusnetworks.com, linville@...driver.com,
dev@...nvswitch.org, jasowang@...hat.com, ebiederm@...ssion.com,
nicolas.dichtel@...nd.com, ryazanov.s.a@...il.com,
buytenh@...tstofly.org, aviadr@...lanox.com, nbd@...nwrt.org,
alexei.starovoitov@...il.com, Neil.Jerram@...aswitch.com,
ronye@...lanox.com, simon.horman@...ronome.com,
alexander.h.duyck@...el.com
Subject: Re: [patch net-next v2 8/9] switchdev: introduce Netlink API
On 09/19/2014 10:57 AM, Jamal Hadi Salim wrote:
> On 09/19/14 11:49, Jiri Pirko wrote:
>> Fri, Sep 19, 2014 at 05:25:48PM CEST, jhs@...atatu.com wrote:
>
>>> 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.
>>
>
> It is - thanks Jiri.
>
> cheers,
> jamal
Hi Jiri,
I was considering a slightly different approach where the
device would report via netlink the fields/actions it
supported rather than creating pre-defined enums for every
possible key.
I already need to have an API to report fields/matches
that are being supported why not have the device report
the headers as header fields (len, offset) and the
associated parse graph the hardware uses? Vendors should
have this already to describe/design their real hardware.
As always its better to have code and when I get some
time I'll try to write it up. Maybe its just a separate
classifier although I don't actually want two hardware
flow APIs.
I see you dropped the RFC tag are you proposing we include
this now?
.John
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists