History

io_uring: add support for backlogged CQ ring

Currently we drop completion events, if the CQ ring is full. That's fine for requests with bounded completion times, but it may make it harder or impossible to use io_uring with networked IO where request completion times are generally unbounded. Or with POLL, for example, which is also unbounded. After this patch, we never overflow the ring, we simply store requests in a backlog for later flushing. This flushing is done automatically by the kernel. To prevent the backlog from growing indefinitely, if the backlog is non-empty, we apply back pressure on IO submissions. Any attempt to submit new IO with a non-empty backlog will get an -EBUSY return from the kernel. This is a signal to the application that it has backlogged CQ events, and that it must reap those before being allowed to submit more IO. Note that if we do return -EBUSY, we will have filled whatever backlogged events into the CQ ring first, if there's room. This means the application can safely reap events WITHOUT entering the kernel and waiting for them, they are already available in the CQ ring.

Jens Axboe committed 7 years ago

Commit 1d7bb1d1 parent 78e19bb2 files · +103 −23Browse files

Showing the changes to include/uapi/linux (1 of 2 files). Show all

Unified · Split

include/uapi/linux/io_uring.h+1−0
@@ -155,6 +155,7 @@ struct io_uring_params { · 154 unmodified lines
155 * io_uring_params->features flags155 * io_uring_params->features flags
156 */156 */
157#define IORING_FEAT_SINGLE_MMAP (1U << 0)157#define IORING_FEAT_SINGLE_MMAP (1U << 0)
158#define IORING_FEAT_NODROP (1U << 1)
158 159
159/*160/*
160 * io_uring_register(2) opcodes and arguments161 * io_uring_register(2) opcodes and arguments