News for hackers. Stuff that matters.
Re:Why you should use io_uring for network I/O by philosopher1234 on Wednesday April 12, 2023 @07:14PM (#35548384)
You cant leave me hanging!! Whats the genius idea?
Re:Why you should use io_uring for network I/O by shorodei on Wednesday April 12, 2023 @07:25PM (#35548496)
You could use the shared ring buffers scheme to replace essentially all syscalls and similar things in any context. Think gpu drivers, memory controllers, etc. It could be a universal interface for all communication that has to go through some kind of expensive security barrier.
Re:Why you should use io_uring for network I/O by vluft on Wednesday April 12, 2023 @09:59PM (#35549883)
With cross-core interrupts and user-mode interrupt handlers (as in some new intel cpus), you could even do something without polling (interrupt for submission) where the core user-mode code is running on _never_ context switches (obviously except for scheduling) and you just have a dedicated kernel core or cores off doing kernel things.
Re:Why you should use io_uring for network I/O by benlwalker on Wednesday April 12, 2023 @10:25PM (#35550066)
You can also use umwait on the next completion entry in the ring
Re:Why you should use io_uring for network I/O by vluft on Thursday April 13, 2023 @09:18AM (#35554970)
yup, though that means you're wasting that core's compute; something with green threads where language runtime does a cross-core interrupt to submit syscall then continues execing other green threads until it gets a user interrupt for syscall completion would be pretty neat.

(ETA: and indeed looks like they're considering support for that in io_uring! https://lwn.net/Articles/869140/)

Re:Why you should use io_uring for network I/O by mattclarkdotnet on Wednesday April 12, 2023 @07:24PM (#35548487)
“General purpose syscall batching”, which drastically cuts down on context switches
Re:Why you should use io_uring for network I/O by benlwalker on Wednesday April 12, 2023 @08:18PM (#35549053)
Imagine you have a piece of software that runs in an event loop (as many things do). On each loop, queue up all system calls you'd like to perform. At the end of the loop, do one syscall to execute the batch. At the start of the loop, check if anything has completed and continue the operation.

If you're processing a set of sockets and on any given loop N are ready, then with epoll you do N+1 syscalls. With io_uring you do 1. It's independent of N.

Re:Why you should use io_uring for network I/O by klabb3 on Wednesday April 12, 2023 @09:17PM (#35549559)
And the potential impact is huge! Not only are individual syscalls expensive on their own, and increasingly so (afaik) with spectre and security issues. You also need a thread to execute the call, which is several KB of memory, compound context switches, and (often overlooked) creating and destroying threads also come with syscall overhead.

Now, we’ve had epoll etc so it’s not novel in that respect. However, what’s truly novel is that it’s universal across syscalls, which makes it almost mechanical to port to a new platform. A lot of intricate questions of high-level API design simply go away and become more simple data layout questions. (I’m sure there are little devils hiding in the details, but still)