On 09/20/14 at 10:14am, Jiri Pirko wrote: > Sat, Sep 20, 2014 at 12:12:12AM CEST, john.r.fastab...@intel.com wrote: > >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.
I think this is the right track. I agree with Jamal that there is no need for a new permanent and separate Netlink interface for this. I think this would best be described as a structure of nested Netlink attributes in the form John proposes which is then embedded into existing Netlink interfaces such as rtnetlink and OVS genl. OVS can register new genl ops to check capabilities and insert hardware flows which allows implementation of the offload decision in user space and allows for arbitary combination of hardware and software flows. It also allows to run a eBPF software data path in combination with a hardware flow setup. rtnetlink can embed the nested attribute structure into existing APIs to allow feature capability detection from user space, statistic reporting and optional direct hardware offload if a transaprent offload is not feasible. Would that work for you John? I think we should focus on getting the layering right and make it generic enough so we allow evolving naturally. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
