> kernel/user space context switching, in high performance context has to be seriously evaluated.

Of course. But that's true for all userspace solutions too, and there are many options for async APIs (io_uring et. al.) which work to address that.

The point is that you want the IP stack (or whatever) to be passing stuff around on unix domain sockets for every packet. It's that you want it running in its own memory domain.

I don't think this is actually true (eg. DPDK), but even if it is, you can put the driver in userspace (tun/tap + vfio/libusb/ioport/...) and still use TCP/IP in the kernel.

that's strictly not true. if I move the code that does TCP from the kernel into the application (not some other daemon, which is perhaps what you're suggesting), then the performance is to the first order the same.

ok, what are the niggly details. we don't have interrupts, and we're running under the general scheduler, so there may be some effects from not getting scheduled as aggressively.

we still need to coordinate through the kernel wrt port bindings, since those are global across the machine, but that's just a tiny bit.

clearly we may be re-opening a door to syn-flooding, since the path to rejection is maybe longer. maybe not, but maybe we can leave the 3-way handshake in the kernel and put the datapath in userspace.

we probably lose rtt-estimates hanging off of routes.

none of that suggests 'several times slower'

"Get Pwn3d server times faster!"

Seemingly we've been writing kernels for years, and they still are full of security holes.

But hardware manufacturers love it! Excuse to sell new faster machines.