By the way, what does Rust have to do with their problem? Is Rust simply bad at io_uring? :)
Rust isn't inherently bad at io_uring but at least Tokio currently is. I'm not the one who implemented and benchmarked it so this is second-hand information but if I recall correctly Tokio shares one buffer pool for all threads so as you scale to 100+ threads the whole thing grinds to a halt.
Migrating our I/O to a different async runtime than Tokio was rejected. So we'll wait until it's fixed in Tokio and now use regular blocking reads instead.
* Project exists
* New employees come up with idea for efficiency improvement
* Months spent implementing. Old codepath becomes legacy.
* New thing now has extra features bolted on during build.
* Efficiency of new thing turns out worse than original, but now the new features and 'less technical debt' are the drivers.
* New thing launches, old thing deprecated, but there is little real benefit to all those months of work.
APIs like io_uring, combined with O_DIRECT, allow you to design your own workload-specific userspace scheduler from first principles. If you are delegating scheduling to a runtime then you’ve forfeited most of the performance advantages those APIs were designed to provide. In many cases, the performance will be worse. By contrast, mmap implicitly delegates all scheduling decisions and it has some advantages if delegation is your strategy compared to a runtime.
The benefits of io_uring are limited without a commitment to designing your own schedulers. On the upside, skilled scheduler designers can increase performance by substantial integer factors using these APIs versus mmap. Designing application-specific schedulers is not easy, it is a high-skill endeavor. But the reward is real.
Using io_uring well requires going all-in on the software architecture it requires to show what it can do.