io_uring: The Completion-Based Model
Suppose a storage service needs to perform 64 independent file reads.
With traditional blocking I/O, it may use many threads, but each waiting thread consumes memory and scheduler resources. Readiness-based APIs are also less useful for regular files than they are for sockets.
Linux **io_uring** provides a completion-based alternative. The application submits I/O operations through a shared ring, and the kernel places completed results into another ring.
For example, the application might submit reads A, B, C, and D, continue doing other work, and receive completions in the order C, A, D, B.
The main benefits are:
- Keep many I/O operations in flight without one blocked thread per operation.
- Reduce system-call overhead by batching submissions and completions through shared rings.
io_uring does not make every workload faster or eliminate every copy. Its main advantage is an efficient and flexible model for submitting and completing asynchronous I/O.
This chapter explains submission and completion rings, request and buffer lifetimes, batching, queue depth, ordering, cancellation, and error handling, then compares io_uring with readiness-based interfaces such as epoll.