There is actually a patch to enable AF_XDP for DPDK:
http://mails.dpdk.org/archives/dev/2018-August/109792.htmlAnd 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.
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.