On Mon, Mar 22, 2021 at 08:46:04PM -0700, Sagi Grimberg wrote:
>
> > +static void blk_bio_poll_post_submit(struct bio *bio, blk_qc_t cookie)
> > +{
> > + bio->bi_iter.bi_private_data = cookie;
> > +}
> > +
>
> Hey Ming, thinking about nvme-mpath, I'm thinking that this should be
> an exported function for failover. nvme-mpath updates bio.bi_dev
> when re-submitting I/Os to an alternate path, so I'm thinking
> that if this function is exported then nvme-mpath could do as little
> as the below to allow polling?
>
> --
> diff --git a/drivers/nvme/host/multipath.c b/drivers/nvme/host/multipath.c
> index 92adebfaf86f..e562e296153b 100644
> --- a/drivers/nvme/host/multipath.c
> +++ b/drivers/nvme/host/multipath.c
> @@ -345,6 +345,7 @@ static void nvme_requeue_work(struct work_struct *work)
> struct nvme_ns_head *head =
> container_of(work, struct nvme_ns_head, requeue_work);
> struct bio *bio, *next;
> + blk_qc_t cookie;
>
> spin_lock_irq(&head->requeue_lock);
> next = bio_list_get(&head->requeue_list);
> @@ -359,7 +360,8 @@ static void nvme_requeue_work(struct work_struct *work)
> * path.
> */
> bio_set_dev(bio, head->disk->part0);
> - submit_bio_noacct(bio);
> + cookie = submit_bio_noacct(bio);
> + blk_bio_poll_post_submit(bio, cookie);
> }
> }
> --
>
> I/O failover will create misalignment from the polling context cpu and
> the submission cpu (running requeue_work), but I don't see if there is
> something that would break here...
I understand requeue shouldn't be one usual event, and I guess it is just
fine to fallback to IRQ based mode?
This patchset actually doesn't cover such bio submission from kernel context.
--
Ming
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/dm-devel
