Jens just picked a patchset to enable hybrid polling in io_uring.
We see big improvements on CPU utilization, specially on the read path (up to 70%).
Continuous improvements in the I/O Path in terms of core cost per I/O are critical for the adoption of new PCIe generations. And this is not only for storage devices; io_uring is already used in networking, and I believe we will see it being used for user-space driven accelerators.
@KayEss I don’t share your negative prognosis on the amount of R&D time required. My team has successfully converted large C-language codebases to io_uring which were much further away from io_uring than beam is.
As I stated earlier in the test, the main issue I see is whether or not there is an accessible/published test suite to validate the developments. If anyone could point me what kind of tests suites for the socket I/O part of beam exist, I’d have a look on the coverage they have to determine whether that’s sufficient coverage to confidently say a “pass” of that of a hypothetical io_uring port didn’t break anything.
Do you mean something more other than what is in the test suite(s) for socket or inet ? (note I only linked to two of them).
Also, I recently watched you talk on io_uring, eBPF, XDP and AF_XDP and found it extremely refreshing!
Edit :
I realize in retrospect you’re surely looking for a performance validation suite. I suppose that’s still an assumption, if you could clarify that would help us move this thread forward I believe
Sorry for the late follow-up. Indeed, I was looking for both functional and performance test suites for the beam I/O codebase. If there was something that could be easily run, I might be tempted to give it a shot and see how far I’d get in terms of a time-boxed prototype to hopefully generate some promising figures.
I doubt that anyone outside our team has ever run them, so there are most likely errors in the description on how to do things. It is however something to start with.
