Re: [PATCH 15/15] nvme-multipath: enable polled I/O

Keith Busch
2021-05-12T22:17:24Z

On Wed, May 12, 2021 at 03:10:58PM -0700, Sagi Grimberg wrote:
>
> > Set the poll queue flag to enable polling, given that the multipath
> > node just dispatches the bios to a lower queue.
> >
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > ---
> > drivers/nvme/host/multipath.c | 9 +++++++++
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/drivers/nvme/host/multipath.c b/drivers/nvme/host/multipath.c
> > index 516fe977606d..e95b93655d06 100644
> > --- a/drivers/nvme/host/multipath.c
> > +++ b/drivers/nvme/host/multipath.c
> > @@ -446,6 +446,15 @@ int nvme_mpath_alloc_disk(struct nvme_ctrl *ctrl, struct nvme_ns_head *head)
> > goto out;
> > blk_queue_flag_set(QUEUE_FLAG_NONROT, q);
> > blk_queue_flag_set(QUEUE_FLAG_NOWAIT, q);
> > + /*
> > + * This assumes all controllers that refer to a namespace either
> > + * support poll queues or not. That is not a strict guarantee,
> > + * but if the assumption is wrong the effect is only suboptimal
> > + * performance but not correctness problem.
> > + */
> > + if (ctrl->tagset->nr_maps > HCTX_TYPE_POLL &&
> > + ctrl->tagset->map[HCTX_TYPE_POLL].nr_queues)
> > + blk_queue_flag_set(QUEUE_FLAG_POLL, q);
>
> If one controller does not support polling and the other does, won't
> the block layer fail to map a queue for REQ_POLLED requests?
>
> Maybe clear in the else case here?

This only gets called once per head, though, so it's just going to
inherit whatever capabilities the first controller happens to have. If
we do set QUEUE_FLAG_POLL, but the chosen path happens to not support
it, then submit_bio_checks() will strip off the bio flag and it will be
processed as a non-polled request.

If the first controller can't support a polled queue, then other
controllers that do will just have unusable resources.