Sat, Sep 20, 2014 at 12:12:12AM CEST, john.r.fastab...@intel.com wrote: >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, j...@mojatatu.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.
Hmm, let me think about this a bit more. I will try to figure out how to handle that. Sound logic though. Will try to incorporate the idea in the patchset. > >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. Understood. > >I see you dropped the RFC tag are you proposing we include >this now? v11 is my bet :) > >.John _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
