> > 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.) [Gray, Mark D] Yes, John and I have discussed a lot of this in depth and we have done whiteboarding of possible hw offload designs in OVS which is why I am quite familiar with the issues.
> > 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. [Gray, Mark D] I read your comments on this I had a look through Sugesh's code to try and see where this was happening. I couldn’t see it but I agree that the source port is basically random and it's only a hash of the inner flow by convention. Sugesh, is Jesse's concern valid in your implementation? I thought it was actually extracting the inner header and you weren't making an assumption about the source port? > > 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
