The rapid growth of io_uring [LWN.net]

The rapid growth of io_uring

Posted Jan 27, 2020 0:36 UTC (Mon) by cesarb (subscriber, #6266)
Parent article: The rapid growth of io_uring

One drawback of io_uring seems to be that, as far as I know, you need a separate buffer for each pending request. So if you were using io_uring to read data from 1000 network connections at the same time, you'd need 1000 separate buffers, while with synchronous epoll+read, you'd need a single buffer (1000 times less memory).

Is there any plan to allow the kernel to choose the buffer, so that you could give the kernel a small set of buffers (or a single large buffer) and the kernel would pick one (or carve a piece of that large buffer) when the data arrives? Or is that actually not an issue in real-world use cases?

to post comments

The rapid growth of io_uring

Posted Jan 27, 2020 1:44 UTC (Mon) by farnz (subscriber, #17727) [Link]

While you can't have the kernel choose which buffer is in use for each pending read, you can make use of IORING_OP_POLL_ADD to poll all 1,000 network connections via the uring, and then use IORING_OP_READV to read only from the connections that are ready, using a smaller number of buffers than there are connections.

That's basically the same work level as epoll + read, but with both the epoll and the read being done asynchronously.