Re: [PATCH v5 0/5] io_uring/uring_cmd: allow non-iopoll cmds with IORING_SETUP_IOPOLL

[Jens Axboe <axboe@kernel.dk>]

On 3/17/26 6:47 PM, Caleb Sander Mateos wrote:
> On Mon, Mar 16, 2026 at 6:01 PM Jens Axboe <axboe@kernel.dk> wrote:
>>
>> On 3/16/26 4:14 PM, Jens Axboe wrote:
>>>
>>> On Mon, 02 Mar 2026 10:29:09 -0700, Caleb Sander Mateos wrote:
>>>> Currently, creating an io_uring with IORING_SETUP_IOPOLL requires all
>>>> requests issued to it to support iopoll. This prevents, for example,
>>>> using ublk zero-copy together with IORING_SETUP_IOPOLL, as ublk
>>>> zero-copy buffer registrations are performed using a uring_cmd. There's
>>>> no technical reason why these non-iopoll uring_cmds can't be supported.
>>>> They will either complete synchronously or via an external mechanism
>>>> that calls io_uring_cmd_done(), io_uring_cmd_post_mshot_cqe32(), or
>>>> io_uring_mshot_cmd_post_cqe(), so they don't need to be polled.
>>>>
>>>> [...]
>>>
>>> Applied, thanks!
>>>
>>> [1/5] io_uring: add REQ_F_IOPOLL
>>>       commit: 9165dc4fa969b64c2d4396ee4e1546a719978dd1
>>> [2/5] io_uring: remove iopoll_queue from struct io_issue_def
>>>       commit: 7995be40deb3ab8b5df7bdf0621f33aa546aefa7
>>> [3/5] io_uring: count CQEs in io_iopoll_check()
>>>       commit: 3a5e96d47f7ea37fb6adf37882eec1521f8ca75e
>>> [4/5] io_uring/uring_cmd: allow non-iopoll cmds with IORING_SETUP_IOPOLL
>>>       commit: 23475637b0c47e5028817c9fd4dabe8f7409ca6c
>>> [5/5] nvme: remove nvme_dev_uring_cmd() IO_URING_F_IOPOLL check
>>>       commit: f144dbac4b177cfd026e417ab98da518ff3372cb
>>
>> Caleb, want to send the liburing tests and documentation updates too?
> 
> Sure. What type of file do you recommend using for non-iopoll
> uring_cmds? Most of them seem to have relatively specific hardware
> (e.g. blkdev_uring_cmd, nvme_dev_uring_cmd) or kernel configuration
> (e.g. ublk_ch_uring_cmd, io_mock_cmd) requirements, as well as
> requiring elevated permissions. Maybe io_uring_cmd_sock would be the
> most general?

Yep I think uring_cmd sock commands would be a good choice. Bonus points
if you write the test as such that we can easily plug in future commands
we allow with IOPOLL as well, as I would imagine we'd expand which we
allow going forward once vetted.

-- 
Jens Axboe