On 5/17/23 13:39, Christoph Hellwig wrote:
On Wed, May 17, 2023 at 01:32:53PM +0100, Pavel Begunkov wrote:
1) ublk does secondary batching and so may produce multiple cqes,
that's not supported. I believe Ming sent patches removing it,
but I'd rather not deal with conflicts for now.
2) Some users may have dependencies b/w requests, i.e. a request
will only complete when another request's task_work is executed.
3) There might be use cases when you don't wont it to be delayed,
IO retries would be a good example. I wouldn't also use it for
control paths like ublk_ctrl_uring_cmd.
You speak a lot of some users and some cases when the only users
are ublk and nvme, both of which would obviously benefit.
If you don't want conflicts wait for Ming to finish his work
and then we can do this cleanly and without leaving dead code
around.
Aside that you decided to ignore the third point, that's a
generic interface, not nvme specific, there are patches for
net cmds, someone even tried to use it for drm. How do you
think new users are supposed to appear if the only helper
doing the job can hang the userspace for their use case?
Well, then maybe it'll remain nvme/ublk specific with such
an approach.
It is clean, and it's not dead code, and we should not
remove the simpler and more straightforward helper.
--
Pavel Begunkov
