[baolongtrann]

Maybe I missed something, but the argument that was stated in that talk, "DPDK is not linux," is not very clear to me. How is "not linux" a bad thing?

I'm not saying DPDK is perfect. As an user, here are some of the most annoying things about DPDK:

- 100% CPU, even in down time. There has been works done recently in power management for DPDK but it still is quite limited.

- Debugging is difficult. Valgrind doesn't even work ootb.

- Very limited tool set compared to linux. For example no tcpdump.

- Setting up is cumbersome. Allocating hugepages must be done soon after reboot, NICs must be bound to uio,...

- Ad-hoc Layer 4-7.

That said, some of the packet processing libraries that come with DPDK is awesome. Once you get through the first few hurdles the dev experience is actually quite nice. I think combining DPDK with XDP is very promising.

[cscscsc]

There is actually a patch to enable AF_XDP for DPDK: http://mails.dpdk.org/archives/dev/2018-August/109792.html

And also a recent talk on how AF_XDP can be optimised further to get closer to DPDK speed (http://vger.kernel.org/lpc-networking2018.html#session-11) where it concludes "DPDK still faster for 'notouch', but AF XDP on par when data is touched". And latter is what matters.

I think combining the two definitely has huge potential:

- All the Linux tooling can be used again as drivers in kernel are used.

- No 100% busy polling needed, it's definitely not a must for workloads.

- Easy setup as simply kernel drivers are used as is.

- Vendors only have to maintain their kernel drivers, but not DPDK ones, so less cost

- Users can simply switch from one NIC to another without any hassle

- DPDK library for application development can be fully reused.

Sounds like a big win to me for both worlds.