On Sat, Sep 20, 2014 at 3:53 AM, Thomas Graf <tg...@suug.ch> wrote: > 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 John and Thomas here. I think HW should not be limited by SW abstractions whether these abstractions are called flows, n-tuples, bridge or else. Really looking forward to see "device reporting the headers as header fields (len, offset) and the associated parse graph" as the first step. Another topic that this discussion didn't cover yet is how this all connects to tunnels and what is 'tunnel offloading'. imo flow offloading by itself serves only academic interest. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
