4 ms·
Is it me or does this part make no sense > But moving from TCP to UDP can get you much the same performance without usermode drivers. Instead of calling the we
by nly 8y ago
Is it me or does this part make no sense
> But moving from TCP to UDP can get you much the same performance without usermode drivers. Instead of calling the well-known recv() function to receive a single packet at a time, you can call recvmmsg() to receive a bunch of UDP packets at once.
TCP is a streaming protocol, there are no datagrams to read one at a time. Nothing stops you from reading the entire kernel buffer (containing multiple HTTP messages) in to userspace in one syscall.
- TazeTSchnitzel 8y agoThey're not talking about receiving TCP packets there.
- deleted 8y ago[deleted]
- detaro 8y agoHTTP requests are small, and a read() call only gets you the data from a single connection, so you get one to few packet(s) worth of data per syscall. In contrast, recvmmsg can get you a large bunch of packets across all "connections" in a single syscall.
- nly 8y agoGood point. Only that makes sense for servers though since for clients (web browsers etc) sockets will be 'connected' and they will still have lots of sockets anyway. They'll still be epoll()ing or similar. Not withstanding the other benefits of QUIC, the UDP vs TCP thing wrt to crossing the kernel-userspace boundary doesn't seem that significant.
- detaro 8y agoFor clients these numbers don't matter as much, many thousands of packets per second doesn't really happen to them. For a server with a fast pipe it does happen. I hope one of the big providers will share numbers. I don't think many of them actually use user-space stacks with TCP, would be interesting if QUIC improves performance measurably.
- neopallium 8y agoThe client doesn't have to use a "connected" UDP socket either. The client can bind to a random local port and use "sendto" to talk to many servers.
- ldng 8y agoTCP is not only used for HTTP
- deleted 8y ago[deleted]
- jandrese 8y agoThe problem is from userland you don't get to decide how much data the kernel hands you with the read call, and by default the kernel will try not to let its buffers fill too much so you end up with a lot of context switches as you read out one window's worth of data at a time. You could do something similar with TCP if there were kernel support, but the article suggests that putting this much complexity in the kernel's TCP stack is a bad idea because it increases the chance of failure--which can be catastrophic in kernel space. Better to have your web browser/server crash instead of the entire machine.