There is a busy restaurant on the east side of town. The kitchen is in the back courtyard, the dining hall up front, and between them stands a thick wall with a single small door.

The old system worked like this: a customer orders, the waiter pushes open the door, walks into the kitchen, hands the slip to the chef, and stands there waiting. When the dish is done, the waiter carries it back through the door, sets it on the table, and walks back for the next one. One door, back and forth. On a busy night the waiters queue up at the door — the dining hall screams for food, the kitchen screams for someone to carry plates.

Then the owner had an idea. He bricked up the small door. In its place he cut a wide pass-through in the wall and installed two lazy Susans — continuous loop turntables, one spinning from the dining hall into the kitchen, the other spinning from the kitchen out to the hall.

The rules changed.

No waiter pushes a door anymore. He writes the order on a slip, drops it into an empty slot on the inbound turntable, and the turntable carries it into the kitchen. On the other side, a kitchen runner watches the turntable, plucks each slip off, and hands it to the chef. When a dish is ready, the runner sets the plate on a slot of the outbound turntable, and it glides into the dining hall. Out front, the waiter sees the plate appear, picks it up, and delivers it.

Nobody walks through the door.

The waiter is fast now: write a slip, drop it in a slot, turn around and greet the next table — he can stuff five or six slips in a row before even glancing at the outbound turntable for finished plates. The kitchen works the same way: the chef pulls slips in batches, fires dishes in batches, never waiting for a waiter to show up one trip at a time.

The turntables are loops — a fixed number of slots, and when they come around they start over. Full means full: if the inbound turntable has no empty slots, the waiter waits until one clears. Same on the return: if the outbound turntable is packed, the kitchen waits for a waiter to pick up a plate. But as long as both sides keep moving and don’t stop, the flow never breaks.

A clever waiter discovered something else: he can pre-load slips for the signature dishes that the next table is almost certain to order — before the customer even speaks, the turntable is already carrying the order in. The food arrives so fast it feels like magic.

A new waiter once asked an old hand: “Before, when I pushed the door open, I could only carry one slip at a time, and I had to stand at the door waiting for the chef to take it. Now I can drop ten slips without leaving the dining hall. What exactly am I saving?”

The old hand smiled: “You’re saving the door. Every time you pushed it, the latch had to open, close, lock, and check your face — that whole routine took longer than cooking the dish. Now you drop the slip in a slot and you don’t even need to know where the door used to be.”

— By now you’ve probably recognized it: this is io_uring.

What it is

io_uring is an asynchronous I/O framework introduced in Linux 5.1 (2019). It shares two ring buffers between userspace and kernel: the Submission Queue (SQ) and the Completion Queue (CQ). An application fills I/O requests (read, write, accept, send, recv, …) into empty slots of the SQ. The kernel picks requests out of the SQ, executes them, and drops results into the CQ. The application then harvests results from the CQ.

The key advantage: no syscall needed per I/O operation. A traditional read/write requires one user→kernel→user context switch per call (plus security checks). Under high concurrency, this overhead — “the door” — dwarfs the actual I/O. io_uring batches many requests into a single io_uring_enter call, or in polling mode, uses zero syscalls at all; both sides communicate only through shared memory.

Why it matters

In network-intensive (Nginx, database proxies, storage engines) and disk-intensive (RocksDB, Ceph) workloads, io_uring outperforms the traditional epoll + thread-pool model by 30%–300%, because it eliminates the dominant fixed cost: syscall context switching. It is also the only general-purpose interface on Linux that delivers truly asynchronous disk I/O (the older aio subsystem only supports direct I/O with heavy restrictions). If you run high-throughput Kubernetes workloads — databases, message queues, object stores — the engine underneath is very likely already using io_uring. Understanding its ring semantics, backpressure behavior (SQ-full blocks submission), and polling-mode tradeoffs directly affects whether you tune nr_requests, iodepth, and CPU affinity correctly.

Metaphor mapping

• kitchen in the back, dining hall up front, thick wall between them → kernel space and userspace, isolated
• pushing the door, handing a slip, standing there waiting → a traditional read/write syscall, one context switch per call
• the latch opening, closing, locking, checking your face → syscall overhead: context switch + security checks
• bricking the door, cutting a pass-through, installing two turntables → io_uring_setup, creating the shared ring buffers
• the inbound turntable (dining hall → kitchen) → the Submission Queue (SQ), where the app drops I/O requests
• the outbound turntable (kitchen → dining hall) → the Completion Queue (CQ), where the kernel drops results
• a slip dropped into a slot → writing one SQE (Submission Queue Entry)
• a plate placed on the return slot → the kernel writing one CQE (Completion Queue Entry)
• stuffing five or six slips before looking at the outbound side → batched submission, one io_uring_enter for many requests
• turntable is a loop, full means wait → ring buffer is fixed-size, SQ-full means backpressure
• pre-loading slips for the signature dish → pre-registered buffers / fixed files, reducing per-request setup cost
• nobody walks through the door → polling mode, zero syscalls, pure shared-memory communication
• waiter and chef each working nonstop, independently → userspace and kernel running asynchronously in parallel, pipelined