There has been a lot of applications/stack built around DPDK last few years. Mostly because people found it easy to code stuff around DPDK and are so happy to display perf graph about their DPDK application vs plain Linux Kernel stack.

My intention here would be to warn a little bit about this collective enthusiasm around DPDK. Integrating DPDK is easy and mostly fun (even if you have to learn and dig into their rte lib and mbuf related), but most of people are completely blind about security ! Ok Linux kernel and netdev is slow in respect of NIC available nowadays (10G, 40G and multiple 100G on core-networks), but using Linux TCP/IP stack you will benefit the hardcore hacking task done during last 30years by Linux netdev core guys ! this long process mostly fix and solve hardcore issues and for some : security issues. And you will certainly not be protected by a 'super fast' self proclaimed performance soft. Mostly because these applications are mostly features oriented than security or protocol full-picture, and are using this 'super fast, best of ever' argument to enforce people mind to adopt.

The way DPDK is working in polling mode is certainly not the best at all. DPDK is PCI 'stealing' NIC from kernel to handle/manage itself in userspace by forcing active loop (100% CPU polling) to handle descriptors and convert to mbuf. latter you can 'forward' mbuf to Linux kernel by using KNI netdevice to use Linux Kernel machinery as a slow-path for complicated/not_focused packet-flow (most application are using KNI for ARP,DHCP,...). But most of the time application are implementing 'minimal' adjacent network features to make it work in its networking environment : and here is the problem: you are focused on perf and because of it you are making shortcut about considering potential threats... a prediction could be to see large number of network security holes opened, and specially an old bunch of security holes making a fun revival (a lot of fun with TCP)

In contrast recent Linux Kernel introduced XDP and eBPF machinery that are certainly much more future proof than DPDK. First consideration in XDP design is : you only TAP in data/packet you are interested in and not making an hold-up on whole traffic. So XDP is for fast path but only for protocol or workflow identified. You program and attach an eBPF program to a specific NIC, if there is no match then packet simply continue its journey into Linux Kernel stack.

XDP is a response from kernel netdev community to address DPDK users. The fact that DPDK introduced and extended PMP to support AF_XDP is certainly a sign that XDP is going/doing into the right direction.


On 12/02/2019 14:04, Federico Iezzi wrote:
Nowadays most VNF (virtual network function) in the telco operators are built around DPDK. Not demos, most 5G will be like that. 4G is migrating as we speak on this new architecture. There isn't any TCP stack built-it but the libraries can be used to build one. VPP has integrated DPDK in this way.

Linux network stack is not designed to managed millions of packets per second, DPDK bypass it completely offloading everything in userspace. The beauty is that also the physical nic drivers are in userspace using specific DPDK drivers. Linux networking stack works in interrupt mode, DPDK is in polling mode, basically with a while true.

 From F5 at the dpdk summit as a relevant reference to what HAProxy does.


On Tue, 12 Feb 2019 at 11:08, Julien Laffaye < <>> wrote:

    Something like or ? :)

    On Mon, Feb 11, 2019 at 11:25 AM Baptiste <
    <>> wrote:


        HAProxy requires a TCP stack below it. DPDK itself is not enough.


Reply via email to