Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux Kernel vs. DPDK: HTTP Performance Showdown

talawah.io

Post reply on HN
Print view View original

31–40 of 72 posts

Re: Linux Kernel vs. DPDK: HTTP Performance Showdown

#31

Post by shaklee3 »

harpratap wrote: post #23
0xbadcafebee wrote: post #9

For those like me going "......what is dpdk" The Data Plane Development Kit (DPDK) is an open source software project managed by the Linux Foundation. It provides a set of data plane libraries and network interface controller polling-mode drivers for offloading TCP packet processing from the operating system kernel to processes running in user space. This offloading achieves higher computing efficiency and higher pac…

How does this differ from eBPF?

dpdk is more equivalent to xdp. ebpf is not really comparable since it can't do large programs within a bpf kernel. dpdk is much, much more than just a packet processing framework.

Re: Linux Kernel vs. DPDK: HTTP Performance Showdown

#32

Post by shaklee3 »

jaimex2 wrote: post #21
0xbadcafebee wrote: post #9

For those like me going "......what is dpdk" The Data Plane Development Kit (DPDK) is an open source software project managed by the Linux Foundation. It provides a set of data plane libraries and network interface controller polling-mode drivers for offloading TCP packet processing from the operating system kernel to processes running in user space. This offloading achieves higher computing efficiency and higher pac…

Basically its what people who want to bypass the kernel network stack because they think its slow. They then spend the next few years writing their own stack till they realise they've just re-written what the kernel does and its slower and full of exploits. Yeah, receiving packets is fast when you aren't doing anything with them.

this is completely wrong. as the article points out, there are plenty of tcp stacks and other user space stacks available. dpdk is used in places where performance matters, and just because you haven't worked in that area doesn't mean it's useless. all telcos use it for the most part.

Re: Linux Kernel vs. DPDK: HTTP Performance Showdown

#33

Post by shaklee3 »

benou wrote: post #28
galangalalgol wrote: post #16

Earlier quoted context omitted.

Is there a good comparison of these technologies? I've used dpdk for high rate streaming data and it roughly doubled my throughput over 10GE. I hear people using things like dma over Ethernet, and it sounds like there are several competing technologies. My use case is to get something from phy layer into gpu memory as fast as possible, latency is less important than throughput.

What you're looking for is RDMA. It was mostly restricted to Infiniband (IB) back in the days, but nowadays you probably want RoCEv2. You can look at iWARP too but I think nowadays RoCE won. In any case, the standard software API for RDMA is ibverbs. All adapters supporting RDMA (be it IB, RoCE or iWARP) will expose it. You can get cloud instances with RDMA on AWS and Azure.

dpdk has rdma/GPUdirect now as well

Re: Linux Kernel vs. DPDK: HTTP Performance Showdown

#35

Post by wumpus »

jaimex2 wrote: post #21
0xbadcafebee wrote: post #9

For those like me going "......what is dpdk" The Data Plane Development Kit (DPDK) is an open source software project managed by the Linux Foundation. It provides a set of data plane libraries and network interface controller polling-mode drivers for offloading TCP packet processing from the operating system kernel to processes running in user space. This offloading achieves higher computing efficiency and higher pac…

Basically its what people who want to bypass the kernel network stack because they think its slow. They then spend the next few years writing their own stack till they realise they've just re-written what the kernel does and its slower and full of exploits. Yeah, receiving packets is fast when you aren't doing anything with them.

> They then spend the next few years writing their own stack

Supercomputing people have done this repeatedly and successfully.

A more general purpose stack is UDP-based applications.

I wouldn't do this with TCP, which I agree is complicated and difficult to get right.

Re: Linux Kernel vs. DPDK: HTTP Performance Showdown

#36

Post by anonymoushn »

evgpbfhnr wrote: post #5

At the point you've gotten syscall overhead is definitely going to be a big thing (even without spectre mitigations enabled) -- I'd be very curious to see how far a similar io_uring benchmark would get you. It supports IOPOLL (polling of the socket) and SQPOLL (kernel side polling of the request queue) so hopefully the fact that application driving it is in another thread wouldn't slow it too much... With multi-shot…

IOPOLL is for disks. I think that with very recent kernels you will get busy polling of the socket with just SQPOLL. See here: https://github.com/axboe/liburing/issues/345#issuecomment-10...

Re: Linux Kernel vs. DPDK: HTTP Performance Showdown

#37

Post by anonymoushn »

limoce wrote: post #15

I am not 100% sure that all of the mitigation overhead comes from syscalls, but it stands to reason that a lot of it arises from security hardening in user-to-kernel and kernel-to-user transitions. Will io_uring be also affected by Spectre mitigations given it has eliminated most kernel/user switches? And did anyone do a head-to-head comparison between io_uring and DPDK?

You can use io_uring with 0 steady-state context switches if you're willing to use 100% CPU on 2 cores :)

Re: Linux Kernel vs. DPDK: HTTP Performance Showdown

#38

Post by olodus »

evgpbfhnr wrote: post #5

At the point you've gotten syscall overhead is definitely going to be a big thing (even without spectre mitigations enabled) -- I'd be very curious to see how far a similar io_uring benchmark would get you. It supports IOPOLL (polling of the socket) and SQPOLL (kernel side polling of the request queue) so hopefully the fact that application driving it is in another thread wouldn't slow it too much... With multi-shot…

Yes, I would be very interested in that as well. I work with a DPDK based app and have sometimes thought about how close to the same performance we could get by using as many kernel optimizations as possible (io_uring, xdp, I don't know what else). It would be an interesting option to give the app since it would greatly simplify the deployment sometimes, as dealing with the DPDK drivers and passthrough in a container and cloud world isn't always the easiest thing.

Re: Linux Kernel vs. DPDK: HTTP Performance Showdown

#39

Post by fulafel »

tomohawk wrote: post #2

From: https://talawah.io/blog/extreme-http-performance-tuning-one-... > I am genuinely interested in hearing the opinions of more security experts on this (turning off speculative execution mitigatins). If this is your area of expertise, feel free to leave a comment Are these generally safe if you have a machine that does not have multi-user access and is in a security boundary?

Browser tabs from different origins are equivalent of the multi-user access here, at least in cases where the speculative execution vulnerability can be exploited from JS. Same for other workloads where untrusted parties have a sufficient degree of control on what code executes.

Generally.. depends on what you mean by generally. In the casual sense of the word, speculative execution attacks are not very common, so it can be said that most people are mostly safe from them independent of mitigations. Someone might also use "generally safe" to mean proven security against a whole class of attacks, in which case the answer would be no.

Re: Linux Kernel vs. DPDK: HTTP Performance Showdown

#40

Post by bitcharmer »

medawsonjr wrote: post #18
pclmulqdq wrote: post #3

This was a fascinating read and the kernel does quite nicely in comparison - 66% of DPDK performance is amazing. That said, the article completely nails the performance advantage: DPDK doesn't do a lot of stuff that the kernel does. That stuff takes time. If I recall correctly, DPDK abstractions themselves cost a bit of NIC performance, so it might be interesting to see a comparison including a raw NIC-specific kerne…

Or better yet, Mellanox VMA since it's open source (unlike Solarflare OpenOnload) and the NICs are far less expensive.

That's not true. OpenOnload is open source:

https://github.com/majek/openonload

Post reply on HN