←back to thread

252 points Klasiaster | 1 comments | | HN request time: 0.198s | source
Show context
justmarc ◴[] No.41853080[source]
I'm interested in these kind of kernels to run very high performance network/IO specific services on bare metal, with minimal system complexity/overheads and hopefully better (potential) stability and security.

The big concern I have however is hardware support, specifically networking hardware.

I think a very interesting approach would be to boot the machine with a FreeBSD or Linux kernel, just for the purposes of hardware as well as network support, and use a sort of Rust OS/abstraction layer for the rest, bypassing or simply not using the originally booted kernel for all user land specific stuff.

replies(4): >>41853111 #>>41853348 #>>41853724 #>>41855929 #
cgh ◴[] No.41853348[source]
If you want truly high-performance networking, you can bypass the kernel altogether with DPDK. So you don't have to worry about alternative kernels for other tasks at all. On the downside, DPDK takes over the NIC entirely, removing the kernel from the equation, so if you need the kernel to see network traffic for some reason, it won't work for you.

You can check out hardware support here: https://core.dpdk.org/supported/nics/

replies(1): >>41853538 #
jauntywundrkind ◴[] No.41853538[source]
This was true a decade ago, with modern io_uring dpdk is probably an anti-pattern.
replies(3): >>41853574 #>>41854804 #>>41857329 #
1. monocasa ◴[] No.41854804[source]
I'm not sure that's true for a good chunk of the workloads that dpdk really shines on.

A lot of the benefit of dpdk is colocating your data and network stack in the same virtual memory context. io_uring I can see getting you there if you have you're serving fixed files as a cdn kind of like netflix's appliances, but for cases where you're actually doing branchy work on the individual requests, dpdk is probably a little easier to scale up to the faster network cards.