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'