I realize that the recommended way to use io_uring is to have one ring per thread. Unfortunately this is not something that we can easily do in our application architecture. Instead, we'd like multiple threads to submit to the same ring. The most straightforward way to do this is to have separate submission and a completion threads. Users that want to do IO submit to a queue that's monitored by the submission thread, which prepares the IOs and submits them to the ring. The completion thread waits for CQEs and calls associated callbacks.
I was trying to come up with a way to not have a submission thread, but allow users to directly submit to a ring. This would save the time to wake up the submission thread. Ideally, the code that I'd like to write is this:
With a ring_lock held:
get SQEs
prepare commands into ring
With a submit_lock held:
with ring_lock held:
num_entries = __io_uring_flush_sq(ring);
if num_entries is not zero, call io_uring_enter(ring->ring_fd, num_entries, 0, 0, nullptr);
In low contention situations a requestor can start the IO right away. In higher contention situations, it should be no worse than having a separate thread. We also get automatic batching.
Would this be a good use case and justification to add io_uring_flush_sq() to the liburing public interface?
You can add a new function to liburing without side effects of io_uring_flush_sq(), but why not count it in the userspace instead? you're locked anyway
I realize that the recommended way to use io_uring is to have one ring per thread. Unfortunately this is not something that we can easily do in our application architecture. Instead, we'd like multiple threads to submit to the same ring. The most straightforward way to do this is to have separate submission and a completion threads. Users that want to do IO submit to a queue that's monitored by the submission thread, which prepares the IOs and submits them to the ring. The completion thread waits for CQEs and calls associated callbacks.
I was trying to come up with a way to not have a submission thread, but allow users to directly submit to a ring. This would save the time to wake up the submission thread. Ideally, the code that I'd like to write is this:
ring_lock
held:submit_lock
held:ring_lock
held:In low contention situations a requestor can start the IO right away. In higher contention situations, it should be no worse than having a separate thread. We also get automatic batching.
Would this be a good use case and justification to add
io_uring_flush_sq()
to the liburing public interface?