> My understand is that XDP is all about programmibility, if user > decides to go for XDP then simply fully implement the fast path is the > XDP framework? I know of software already does so and they are > perfectly fine with this approach. Yes, you can do that. But if you're reimplementing everything anyway, why bother with XDP at all? Might as well go with DPDK and full bypass then. The benefit of XDP as a data path is the integration with the kernel infrastructure: we have robust implementations of a bunch of protocols, a control plane API that works with a bunch of userspace utilities (e.g., routing daemons), and lots of data battle-tested data structures for various things (e.g., the routing table fib). With XDP, you can use this infrastructure in a pick-and-choose manner and implement your fast path using just the features you care about for your use case, gaining performance while still using the kernel path for the slow path to get full functionality. The first example of this paradigm was the bpf_fib_lookup() helper. With this you can accelerate the forwarding fast path and still have the kernel stack handle neighbour lookup, etc. Adding flowtable lookup support is a natural extension of this, adding another integration point you can use for a more complete forwarding acceleration, while still integrating with the rest of the stack. This was the "making XDP a magical go faster button" thing I was talking about at Netconf (and again at Netdevconf), BTW: we should work towards making XDP a complete (forwarding) acceleration solution, so we can replace all the crappy hardware "fast path" and kernel bypass implementations in the world :) -Toke
