Hi all. Wow so much feedback, thanks all for the answers ;-)
Am 12.02.2019 um 15:23 schrieb Alexandre Cassen: > 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. Would you like to share such a comparison? > 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. When I take a look into the doc then I see some security informations. https://doc.dpdk.org/guides/prog_guide/rte_security.html How does such a application handle the security topic? > 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) So this means that a application can be used with DPDK when it uses the KNI (=Kernel NIC Interface) right? https://doc.dpdk.org/guides/prog_guide/kernel_nic_interface.html How much "slower" is the way via KNI? > 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. Sounds a interesting future for the linux kernel. When we take a look into the container and cloud world, does this DPDK makes any sense? I mean when I run a container on AWS/Google/Azure I'm normally so far from any Hardware that this high traffic possibility isn't available for the container, right? To the list members: Maybe it's offtopic from the HAProxy list so please apologize for all the noise. > regs, > Alexandre Regards Aleks > 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 <[email protected] >> <mailto:[email protected]>> wrote: >> >> Something like http://seastar.io/ or https://fd.io/ ? :) >> >> On Mon, Feb 11, 2019 at 11:25 AM Baptiste <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi, >> >> HAProxy requires a TCP stack below it. DPDK itself is not enough. >> >> Baptiste >> >
