New queuing mechanisms are generally much bigger shocks than may meet the eye, and it's unusual to see existing systems and frameworks be able to take full advantage of them immediately. In this case, the Go runtime is playing the part of a "framework"; it has ideas about how system calls work and those ideas come from a pre-io_uring world.

IIRC, the same thing happened back when epoll was new. You couldn't just swap out your select-based framework to epoll with no changes and just magically get the new performance; it required a lot of work and years for things to finally get polished up.

It always seems so easy at the high level, but these abstractions are at the very foundation of the system and the slightest change ripples everywhere. The link you show provides a great demonstration of that; the first paragraph is an optimistic "it seems feasible", then there's literally pages of "umm, well, if you think about this it's a bit more complicated than it seems" and cross-platform issues and upgrades to the kernel mechanism that solved other people's problems maybe solving these problems too and details details details.

That's not to say it won't ever happen. Like I said, epoll and other similar things all went through the same basic process, so it can be done, has been done, and will be done again (if not in Go, then in other places). It's just that it's all so much harder than it looks from 30,000 feet in the air.

Likewise for Mio (which underlies Tokio) for Rust. The odds of that happening look better, but still seems far away.

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.

Very interesting! Thanks for sharing.

We've been able to do a lot with this:

https://github.com/dshulyak/uring

why do you need io_uring from Go? It has a nicer interface than epoll but you’re not coding to its interface.

I don’t know enough to say for sure in this case, but if there’s one issue I have with Go performance, it’s the excessive syscall overhead for standard networking stuff. If you do high bandwidth or high concurrency you often waste a large fraction in syscalls, which can be reduced greatly in theory.

For instance, socket deadlines have iirc 2 syscalls per timeout extension, which is sold as best practice for network timeouts.

why would one use socket deadlines in Go? In Go you would typically just use Context.Deadline or a select and timer mechanism to implement timeouts - and the runtime manages those via timers integrated into the runtime. Socket timeouts are for blocking IO, which Go doesn't use.