On Wed, Jul 20, 2016 at 6:43 PM, Gray, Mark D <mark.d.g...@intel.com> wrote: > [Gray, Mark D] I think we should focus on one or two use cases rather than > a general offload like you discuss below. A general offload involves a huge > amount of code > churn and there are a lot of difficulties, some that you have highlighted > below. > A more focused implementation will flush out any issues with the API. In > particular, > the VxLAN use case that you mentioned above and perhaps the offload of the > hash > calculation (but the generic filtering api would also need to support > generation of hashes) > could be two targets for this DPDK api.
I agree that targeting a specific use case is a good idea (as well as your other comments). It's probably worthwhile talking to John Fastabend about this (also from Intel) since he has tried to something similar for the past several years in Linux. Many of the general problems listed in the original email turn out to be very difficult. (Examples include capabilities; describing flows in a hardware independent manner is something that OpenFlow tried to tackle for a long time; which flows to offload in the face of table size limits while maintaining correct forwarding behavior; etc.) I think the VXLAN acceleration was a good use case since the vswitch is the owner of the tunnel endpoint and therefore is better equipped to make policy decisions. The main concern that I had with the previous implementation was that it was making assumptions about the contents of the inner flow based on the UDP source port, which is not really safe since that is just a hash. Providing hashes or other flow lookup hints that software can use to accelerate lookups while still actually doing the forwarding itself are also good examples of relatively simpler offloads because there is no danger of violating rules. If a flow can't be offloaded to a hardware flow table then the worst that happens is performance suffers vs. possibly picking a (wrong) lower priority flow. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
