> Indeed, there is no performance benefit from having TCP in the kernel. That's why one of the most common tactics in high-performance networking is to move the TCP stack into userspace.

But a userspace network stack only make sense in single purpose devices/servers, because they have to take over the hardware, right?

On a consumer device many applications can use the network concurrently.

QUIC runs on top of UDP anyway, so userspace libraries use OS UDP facilities, but lose the ability to do better cross-application balancing. Hardware TCP offloading also plays a role of course.

You don't have to take over the hardware to do userspace TCP. You only need the ability to put raw datagrams on the wire (Linux RAW socket, for example). You _can_ take over the device with something like DPDK but that's not necessary. As you correctly say, QUIC uses existing OS-level facilities to communicate over UDP, so there is no reason that several processes on a single host cannot use application-level QUIC stacks concurrently.

It's possible to use kernel facilities to route flows to the right application or stack, and then use that stack to process individual connections.

For example, many network cards support creating multiple virtual network devices, and you could hand a whole such device to a userspace process, but only let it see traffic intended for that device.

Or, finer-grained, you could use a filter to steer certain packet flows to a process, while handling others in the kernel.

I do absolutely think there's value in having native QUIC in the kernel, but then, I also think there's value in having native TLS in the kernel; doesn't mean you always want to use it.