On Mon, May 17, 2021 at 10:25:21PM +0530, Kanchan Joshi wrote:

On Mon, Apr 26, 2021 at 8:46 PM Keith Busch [off-list ref] wrote:

quoted

On Mon, Apr 26, 2021 at 04:43:16PM +0200, Christoph Hellwig wrote:

quoted

On Fri, Apr 23, 2021 at 03:05:58PM -0700, Keith Busch wrote:

quoted

The block layer knows how to deal with polled requests. Let the NVMe
driver use the previously reserved user "flags" fields to define an
option to allocate the request from the polled hardware contexts. If
polling is not enabled, then the block layer will automatically fallback
to a non-polled request.

So this only support synchronous polling for a single command.  What
use case do we have for that?  I think io_uring based polling would
be much more useful once we support NVMe passthrough through that.

There is no significant use case here. I just needed a simple way to
test the polled exec from earlier in the series. It was simple enough so
I included the patch here, but it's really not important compared to the
preceeding patches.

It would be great to see this in at some point; helps in making
passthrough more useful.
I'll look into integrating this with async-passthrough.

Right, async ioctl would really provide better justification for
passthrough polling. I'll post a new version of this series this week to
address the previously submitted feedback, but without this patch for
now.