6 ms·

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

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

cscscsc 8y ago

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