+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?
Well, when it will failover, it will probably be directed to the poll queues. Maybe I'm missing something...
This patchset actually doesn't cover such bio submission from kernel context.
What is the difference? -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
