LWN: Comments on "New approaches to network fast paths"

so the user-space side needs to process those packets quickly otherwise they are simply dropped.

Wol — Thu, 27 Apr 2017 15:31:34 +0000

This seems a good fix to me for the problem (mentioned elsewhere) that "more and more stuff gets crammed into the fast path until the fast path becomes the new slow path".

Have something like this, which by default does nothing. Then it's up to the user to put stuff into it, with the constraint that if too much goes in, packets get dropped at random because the buffers fill. Probably the main use of this would be to fight DDoS, because there you don't really care. By killing bad packets as fast as you can, you increase the chances of the good packets getting through, and you rely on TCP to cope with the packets you didn't intend to drop.

But the devs no longer need to worry about "the fast path becoming the slow path" - this would definitely be for sysadmins to tweak with the simple constraint that you can have heavy traffic, or complex rules, but if you have both then packets will start getting dropped at random. Their pick.

Cheers,
Wol

New approaches to network fast paths

Trou.fr — Thu, 20 Apr 2017 11:31:30 +0000

Adding a full TLS stack and HTTP in the kernel, what could possibly go wrong ? It's just a huge attack surface reachable from outside.

New approaches to network fast paths

jhoblitt — Sat, 15 Apr 2017 14:50:19 +0000

Should that be...

The micro-kernel debate is being updated for the network-centric world.
The micro-kernel debate is being updated for the network-centric world.
The micro-kernel debate is being updated for the network-centric world.
The micro-kernel debate is being updated for the network-centric world.

New approaches to network fast paths

zenaan — Sat, 15 Apr 2017 00:15:18 +0000

Indeed - in kernal HURD multi-server module anyone?

No TLS handshake in kernel

niner — Fri, 14 Apr 2017 11:01:55 +0000

Because they want to filter TLS traffic before it hits the costly path through user space.

No TLS handshake in kernel

mokki — Fri, 14 Apr 2017 09:50:27 +0000

Why not instead copy and extend what FreeBSD has done:
1) TLS handshake is done normally in user space
2) user space uploads the encryption and/or decryption keys to kernel
3) kernel does the encryption/decryption in place
4) socket is now essentially TCP for both kernel and userspace uses

FreeBSD supports the above for now only for sendfile, where there are obvious performance benefits compared to userspace reading file, encrypting it and sending over socket.

Kernel already has the required code to do the encryption/decryption while the TLS handshakes, certificates and other policies are better handled in user space. Kernel also has better HW crypto accelerator support and possibility to do zero-copy operations.

I can also envision a systemwide TLS handshake daemon that could be enabled with socket option. Much easier than current distro work to patch tls libraries written for multiple languages to honour a system wide configuration. It would also be much easier to update single hanshake daemon to support next TLS version or fix bugs.

New approaches to network fast paths

ejr — Thu, 13 Apr 2017 22:28:18 +0000

The micro-kernel debate is being updated for the network-centric world.