Question about asynchronous blk-mq tag waiting for io_uring

Question about asynchronous blk-mq tag waiting for io_uring

[Maks]

From: Maks Ivanov <mi9992828@gmail.com>

Hi,

I read your comment in liburing issue #1492 about callback-based retry
when storage tags are exhausted:

https://github.com/axboe/liburing/issues/1492#issuecomment-4696489936

I'm considering this direction for my bachelor's thesis and would like
to clarify its scope and design.

The initial scope would be io_uring direct reads on raw block devices.
For requests without explicit RWF_NOWAIT, the mechanism would register
a continuation when tag allocation cannot complete immediately, then
retry submission when a tag becomes available.
Explicit RWF_NOWAIT requests would retain their existing
behaviour when tag allocation would require waiting.

Could you clarify a few points?

- Is this still an open direction worth investigating?
- Is there related work or an existing approach I should look at first?
- Which layer should own the continuation: io_uring, the block submission
  path, or blk-mq?
- What lifetime and cancellation constraints would such a mechanism need
  to satisfy?

I would also appreciate pointers to other open problems in io_uring or
the block layer that could suit a focused implementation and validation
project. Existing bug reports, design discussions, or TODOs would be
very helpful.

Thanks,
Maks Ivanov

Re: Question about asynchronous blk-mq tag waiting for io_uring

[Maks Ivanov]

Hi Jens,

Just following up on my question below.

I need to submit a preliminary bachelor's thesis topic next week, so even a brief indication of whether this problem is still relevant and worth investigating would be very helpful.

Thanks,
Maks Ivanov

Re: Question about asynchronous blk-mq tag waiting for io_uring

[Jens Axboe]

On 10/8/26 3:41 PM, Maks wrote:
> From: Maks Ivanov <mi9992828@gmail.com>
> 
> Hi,
> 
> I read your comment in liburing issue #1492 about callback-based retry
> when storage tags are exhausted:
> 
> https://github.com/axboe/liburing/issues/1492#issuecomment-4696489936
> 
> I'm considering this direction for my bachelor's thesis and would like
> to clarify its scope and design.
> 
> The initial scope would be io_uring direct reads on raw block devices.
> For requests without explicit RWF_NOWAIT, the mechanism would register
> a continuation when tag allocation cannot complete immediately, then
> retry submission when a tag becomes available.
> Explicit RWF_NOWAIT requests would retain their existing
> behaviour when tag allocation would require waiting.
> 
> Could you clarify a few points?
> 
> - Is this still an open direction worth investigating?

I think so, yes, as it'd avoid needing to punt to io-wq. Which
is ALWAYS a good thing.

> - Is there related work or an existing approach I should look at first?

Not on the block/storage front. Basically the tag waiting is just
a normal sleep operation for the current task. The alternative
would be to add a private wait_queue_entry to the list instead,
and then retry when you get the callback.

> - Which layer should own the continuation: io_uring, the block submission
>   path, or blk-mq?

Just spit balling here, but it'd be an -EIOCBQUEUED operation on
the io_uring side, even though the operation hasn't really started
yet on the device side. On the block side you'd need to handle this
at tag starvation time. Right now that'd put the current task to
sleep, and then wake it when it can get a tag. With the callback
approach, you'd need to be able to tell in the blk-mq sleep side,
and get access to the wait_queue_entry to use. On the block side,
this would be a 0 return, just like if the IO was queued.

> - What lifetime and cancellation constraints would such a mechanism need
>   to satisfy?

That requires a bit more in-depth analysis to answer. Presumably
the wait_queue_head would have the same life time as the io_uring
request, so if a device is ever torn down with IO queued, then
these entries would need pruning too. I suspect the block side
probably does all of that already, as it'd need to wake tasks
sleeping too.

-- 
Jens Axboe