tokio-uring VS liburing

Link should be: https://github.com/tokio-rs/tokio-uring/blob/master/DESIGN.m...

I feel a bit paralyzed by Fear Of Missing Io_Uring. There's so much awesome streaming stuff about (RisingWave, Materialize, NATS, DataFusion, Velox, many more), but it all feels built on slower legacy system libraries.

It's not heavily used yet, but Rust has a bunch of fairly high visibility efforts. Situation sort of feels similar with http3, where the problem is figuring out what to pick. https://github.com/tokio-rs/tokio-uring https://github.com/bytedance/monoio https://github.com/DataDog/glommio

While Mio will probably not implement uring in its current design, there's https://github.com/tokio-rs/tokio-uring if you want to use io_uring in Rust.

It's still in development, but the Tokio team seems intent on getting good io_uring support at least!

As the README states, the Rust implementation requires a kernel newer than the one that shipped with Ubuntu 20.04 so I think it'll be a while before we'll see significant development among major libraries.

That's what the pool is for: https://github.com/tokio-rs/tokio-uring/blob/master/src/buf/fixed/pool.rs

Tokio supports io_uring (https://github.com/tokio-rs/tokio-uring), so perhaps when it's mature and battle-tested, it'd be easier to transition to it if Cloudflare aren't using it already.

- Tokio suffers from a similar problem

Eg via tokio-uring.

I strongly recommend you to look into io-uring and use async executors that take advantages of it: - tokio-uring (not recommended as it is still undergoing development) - monoio - glommio

This would work in this specific case where we know that there is a maximum rate at which work is produced. Arguably I was hijacking the thread to discuss about a more general problem that I've been thinking about for a while. I have the sense that a ring-buffer that has a wait-free push with some tight bound on latency that doesn't require fixed interval polling on the consumer would be a nice primitive that I certainly could have used at times.

And in fact ... the wait-free wakeup part of this is already there. Now that io_uring has futex support, a producer can enable kernel-side busy polling on the uring, and then submit a FUTEX_WAKE to the ring without doing any sys calls. This Github issue [1] has a nice description.

[1] https://github.com/axboe/liburing/issues/385

I've tinkered around with io_uring on and off for the last couple years. But I think it's really becoming quite cool (not that it wasn't cool before... :)). This was a really interesting post on what's new https://github.com/axboe/liburing/wiki/io_uring-and-networki.... The combination of ring-mapped buffers and multi-shot operations has some really interesting applications for high-performance networking. Hoping over the next year or two we can start to see really bleeding edge networking perf without having to resort to using DPDK :)

Thought I was doing something wrong at first, but after looking at examples and code, I just wasn't able to reach the epoll numbers. Looking on the Github page, there a few issues there with people who found the same thing, with their own examples. #1, #2

To address my own silly questions, yes, one should use the new fixed buffers described in this document: https://github.com/axboe/liburing/wiki/io_uring-and-networki...

We're working on this! https://github.com/axboe/liburing/issues/830