finds.dev← search

// the find

tokio-rs/tokio-uring

★ 1,466 · Rust · MIT · updated Jul 2025

An io_uring backed runtime for Rust

tokio-uring wires io_uring into the Tokio async runtime, giving you kernel-bypass I/O submission queues without leaving the Tokio ecosystem. It targets Linux-only, high-throughput server code where syscall overhead on hot paths actually shows up in profiles. The buffer-ownership model (you hand the buffer to the kernel, get it back when the op completes) is the key design decision everything else flows from.

1. The owned-buffer API is architecturally correct for io_uring — it reflects the actual ownership transfer to the kernel ring, so you can't accidentally use a buffer mid-flight. This isn't just ergonomics, it's preventing a class of memory safety bugs at compile time. 2. Fixed-buffer pool support (register_buffers) is present, which is where the real throughput gains live — registered buffers skip the per-operation kernel mapping overhead. 3. First-party project under tokio-rs, so it tracks upstream Tokio compatibility and won't silently diverge. 4. Zero-copy send (send_zc, sendmsg_zc) is implemented, which matters for network servers pushing large payloads.

1. Single-threaded runtime only — io_uring rings are per-thread, and tokio-uring doesn't abstract multi-ring setups, so you're giving up Tokio's work-stealing thread pool. Scaling to multiple cores means running multiple runtimes yourself. 2. Kernel version requirement is a real deployment problem: anything running Ubuntu 20.04 LTS (kernel 5.4) is out, and many cloud providers lag on kernel versions. This isn't getting better until 5.11+ is genuinely universal. 3. The project readme self-describes as 'very young' and the API surface is incomplete — statx and fallocate are there but the op coverage is spotty compared to what io_uring actually supports. Check the CHANGELOG before depending on any specific op. 4. The owned-buffer API, while correct, is friction: you can't just drop in tokio_uring::fs::File where you have tokio::fs::File — call sites need rewriting, which limits how incrementally you can adopt this.

View on GitHub →

// want more like this?

We dig through GitHub every week and send a few repos picked for what you actually care about — each with an honest take like this one.

Get finds in your inbox → Search again →