Hacker News Reader

Comment by willvarfar | Hacker News Reader

I used to do asynchronous io with epoll, aio etc and spend time benchmarking my servers vs completion ports and kqueue etc.

eventually libraries like Libuv turned up and made my life a lot easier.

Are there any good stats on how io_uring compares to all those older async io stuff?

View on HN

Not bad, according to one test: https://github.com/libuv/libuv/issues/1947#issuecomment-4852....

Note that it might have been optimized more in the meantime.

That is for file IO, for which there were not many working async options available. I think the parent was rather interested in how it compares for IO loads where epoll & co are already alternatives.

Check the PDF that the article references, which also links to https://lore.kernel.org/linux-block/20190116175003.17880-1-a...

epoll doesn't allow you to do async io to local storage, and io_uring doesn't target the network use case, so they are not quite comparable.

Though it was originally designed for block io, IIRC io_uring has since added support for network sockets.

Don't know how it compares to epoll performance-wise.

You have to allocate buffer per socket with io_uring, rather then reuse for each one that is ready. Most applications do this anyway though.

This is addressed in the article comments: https://lwn.net/Articles/810558/.

Eh, nothing stops you from using a single buffer, but with different offsets for each open call. So I don't really see the problem unless you have so much buffer space allocated that it becomes problematic.

A "single buffer, but with different offsets for each open call" is identical to "allocate one buffer per socket" (you "allocated" the per-socket buffer by subdividing a larger allocation). And even if you don't "have so much buffer space allocated that it becomes problematic", it's still a waste of memory.

I think the usual trick of using 0 sized buffers for readiness and just do the read synchronously might work.

In fact io_uring might have direct support for polling now.

> io_uring doesn't target the network use case

There are several io_uring opcodes intended specifically for the network use case, including: IORING_OP_ACCEPT, IORING_OP_CONNECT, IORING_OP_SENDMSG and IORING_OP_RECVMSG.

Did you mean something else by 'target'?

iirc it wasn't created for network IO, but I could be wrong

The reason it was created and what it targets are different things. io_uring is evolving to be a very general way to do async interaction with the kernel, and the way it is built enables high performance also for things that isn't disk IO.

Here are echo servers with

io_uring: https://github.com/frevib/io_uring-echo-server

epoll: https://github.com/frevib/epoll-echo-server

kqueue: https://github.com/frevib/kqueue-echo-server

io_uring performs much better than epoll: https://twitter.com/hielkedv/status/1218891982636027905?s=21

Reply on news.ycombinator.com