News for hackers. Stuff that matters.
Re:QUIC Is Not Quick Enough over Fast Internet by quotemstr on Monday September 09, 2024 @02:37AM (#41485992)
> Yes, uring is fancy, but there’s a tutorial level API middle ground possible that should be safe and 10x less overhead without resorting to uring level complexity.

And the kernel has no business providing this middle-layer API. Why should it? Let people grab whatever they need from the ecosystem. Networking should be like Vulkan: it should have a high-performance, flexible API at the systems level with being "easy to use" a non-goal --- and higher-level facilities on top.

Re:QUIC Is Not Quick Enough over Fast Internet by astrange on Monday September 09, 2024 @06:18AM (#41487035)
The kernel provides networking because it doesn't trust userspace to do it. If you provided a low level networking API you'd have to verify everything a client sends is not malicious or pretending to be from another process. And for the same reason, it'd only work for transmission, not receiving.

That and nobody was able to get performant microkernels working at the time, so we ended up with everything in the monokernel.

If you do trust the client processes then it could be better to just have them read/write IP packets though.

Re:QUIC Is Not Quick Enough over Fast Internet by namibj on Monday September 09, 2024 @07:37AM (#41487541)
Also, it is really easy to do the normal IO "syscall wrappers" on top of io_uring instead, even easily exposing a very simple async/await variant of them that splits out the "block on completion (after which just like normal IO the data buffer has been copied into kernel space)" from the rest of the normal IO syscall, which allow pipelining & coalescing of requests.