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.
regs,
Alexandre
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.
https://dpdksummitnorthamerica2018.sched.com/event/IhiF/dpdk-on-f5-big-ip-virtual-adcs-brent-blood-f5-networks
https://www.youtube.com/watch?v=6zu81p3oTeo
Regards,
Federico
On Tue, 12 Feb 2019 at 11:08, Julien Laffaye <jlaff...@freebsd.org
<mailto:jlaff...@freebsd.org>> wrote:
Something like http://seastar.io/ or https://fd.io/ ? :)
On Mon, Feb 11, 2019 at 11:25 AM Baptiste <bed...@gmail.com
<mailto:bed...@gmail.com>> wrote:
Hi,
HAProxy requires a TCP stack below it. DPDK itself is not enough.
Baptiste
