A TCP/IP stack isn't fundamentally faster for running in user- or kernelspace, but avoiding user/kernel transitions helps. So maximum-performance implementations that don't need to care about playing nice with others might be best off choosing one or the other and staying there; running in userland is then more convenient (but e.g. the TUX in-kernel webserver exists/existed.)
Mind you, most high-performance software doesn't need to go this far, and stuff like PF_RING / Linux' packet_mmap or "batched" systems calls like recvmmsg() (or even read()) further reduces the number userland/kernel transitions.
The vast majority of the time though you need to let multiple processes use the same TCP/IP stack. As soon as you have to do that, moving the TCP/IP stack to userspace means you have to do context switches instead of syscalls.
That is not a good thing if you care about performance.
The kernel implementation does context switches and syscalls. It depends on your usersoace architecture if you have to do context switches, you get to decide.
No. If I use netcat on my Linux machine to connect to a remote machine and send and receive packets, no context switches are involved.
If I want to move the TCP/IP stack to userspace on my Linux machine, how do all the programs I use (firefox, ssh, IRC client) send and receive packets without context switches?
If your answer is to change the userspace architecture and shove everything into one process, you've made isolation _worse_. If you don't, how do you avoid the context switches to talk to the network stack?
The key point is that the network stack has to own shared state, and sending and receiving packets _must_ touch that shared state. If it's accessible to every process (shared memory), you've tossed out isolation and security. If it's not, you have to context switch.
> If your answer is to change the userspace architecture and shove everything into one process, you've made isolation _worse_.
Processes are one way of doing isolation but they're a very crude one (give each thing that needs to be isolated its own address space, swap the whole stack every time you switch tasks). A userspace scheduler (which, sure, would be running within a single process at the UNIX level, but that's the wrong level to be thinking about it) that knows about the details of what it's running can achieve the same level of isolation in a more lightweight way.
netcat does switch into and out of the kernel; you're otherwise correct that userland networking pulls towards a one-process appliance (hence my original "... that don't need to care about playing nice with others").
Mind you, most high-performance software doesn't need to go this far, and stuff like PF_RING / Linux' packet_mmap or "batched" systems calls like recvmmsg() (or even read()) further reduces the number userland/kernel transitions.