IO_uring Continues To Prove Very Exciting: Promising io_uring_spawn Announced

[microcode]

Are there any apps that can even use io_uring ?

Anything that does IO lol. I'm writing a UDP program against it right now; I suspect it'll give me at least 32x the throughput of normal recv in my use case. It'd be nice if OpenBSD had an io_uring impl some day, even nicer if it were source compatible... one can dream.

[cl333r]

Anything that does IO lol. I'm writing a UDP program against it right now; I suspect it'll give me at least 32x the throughput of normal recv in my use case. It'd be nice if OpenBSD had an io_uring impl some day, even nicer if it were source compatible... one can dream.

True but most apps that do IO simply don't need io_uring because they don't do as much IO to make a noticeable difference. For example for me switching in my file browser to io_uring made no noticeable difference replacing epoll+inotify with io_uring+inotify, so I switched back because the epoll+inotify is simpler code.

[F.Ultra]

Anything that does IO lol. I'm writing a UDP program against it right now; I suspect it'll give me at least 32x the throughput of normal recv in my use case. It'd be nice if OpenBSD had an io_uring impl some day, even nicer if it were source compatible... one can dream.

How on earth will it give you 32x the throughput? Do you have that amount of context switch overhead?

IMHO even though it goes against the main design of io_uring I think it would be good if it could expose a synchronous version. For some workloads/applications you simply want to / really need to handle the worker threads manually so it would be nice to just get rid of the context switch overhead.

[NobodyXu]

How on earth will it give you 32x the throughput? Do you have that amount of context switch overhead?

IMHO even though it goes against the main design of io_uring I think it would be good if it could expose a synchronous version. For some workloads/applications you simply want to / really need to handle the worker threads manually so it would be nice to just get rid of the context switch overhead.

io_uring_submit has a parameter where you can specify number of requests to be completed before returning to the userspace.
Thus, it can be used in blocking code, but not sure how useful it will be in practice.

[ThiagoCMC]

Will those significant IO_uring improvements also help QEMU Virtual Machines (VirtIO), OpenvSwitch, and alike?
Today, if you want high throughput in VMs, you kinda need OVS with DPDK at the hosts, which consumes a lot of CPU all the time, but works!
I'm wondering if, with the new IO awesomeness, we could drop DPDK, and reduce CPU consumptions (leave this to Bitcoin miners lol) while not losing in performance.
Pipe dream?

[Zeioth]

Can we users do something to enable it/test it?

[sinepgib]

True but most apps that do IO simply don't need io_uring because they don't do as much IO to make a noticeable difference. For example for me switching in my file browser to io_uring made no noticeable difference replacing epoll+inotify with io_uring+inotify, so I switched back because the epoll+inotify is simpler code.

Yes. There are niches where it could make a big difference, but it's not as universal as some people make it sound. I think probably web servers and p2p clients are the best candidates.

[NobodyXu]

Yes. There are niches where it could make a big difference, but it's not as universal as some people make it sound. I think probably web servers and p2p clients are the best candidates.

Maybe also database as they do a lot of disk I/O, and make/ninja/cargo for taking advantage of the new io_uring_spawn

[sinepgib]

Maybe also database as they do a lot of disk I/O, and make/ninja/cargo for taking advantage of the new io_uring_spawn

Yes. Also the Go runtime could benefit, since it abstracts all IO behind blocking interfaces and io_uring should not hurt. It would also remove lots of IO threads used for async file IO. top is probably a good candidate too I think? Most of the time it'll be reading tiny files.

[NobodyXu]

Yes. Also the Go runtime could benefit, since it abstracts all IO behind blocking interfaces and io_uring should not hurt. It would also remove lots of IO threads used for async file IO.

I think all async runtime can benefit from io-uring to a certain degree.

top is probably a good candidate too I think? Most of the time it'll be reading tiny files.

Yes, and readfile would also be benefit from this because it opens lots of small files.