Except it's several times slower doing TCP/IP in userspace with programs than having a proper kernel for it, that's it, Hurd.

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'

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