[frevib]

For disk IO it’s faster, there are many benchmarks on the internet.

For network IO, it depends. Only two things make it theoretically faster than epoll; io_uring supports batching of requests, and you can save one sys call compared to epoll in an event loop. There some other things that could make it faster like SQPOLL, but this could also hurt performance.

Network IO discussion: https://github.com/axboe/liburing/issues/536

[pengaru]

> Network IO discussion: https://github.com/axboe/liburing/issues/536

I see an issue with a narrative but zero discussion at that link.

Furthermore, your io_uring benchmark being utilized in that issue isn't even batching CQE consumption. I've submitted a quick and dirty untested PR adding rudimentary batching at [0]. Frankly, what seems to be a constant din of poorly-written low-effort benchmarks portraying io_uring in a negative light vs. epoll is getting rather old.

[0] https://github.com/frevib/io_uring-echo-server/pull/16

[tveita]

That seems uncharitable.

The linked issue barely mentions frevib's echo server, and in the one place it does it's the fastest!

Further they show that performance improves when using io_uring for readiness polling but standard read/write calls to actually write - that suggests io_uring_for_each_cqe does not explain the cases where epoll is faster.

> I've submitted a quick and dirty untested PR

That's not improving the situation much then - surely any performance fix should come with at least a rudimentary benchmark?

[jlokier]

In my tests, for NVMe storage I/O I found io_uring was slower than a well-optimised userspace thread pool.

Perhaps the newer kernel is faster, or there is some subtlety in the io_uring queueing parameters that I need to tune better.

[dataflow]

Maybe you're doing large I/Os whereas their benchmarks are doing small random I/Os (like 4K). Are you measuring IOPS or throughout?