* [PATCH v3] nvmet: handle rw's limited retry flag
@ 2024-12-09 1:53 Guixin Liu
2024-12-24 11:30 ` Sagi Grimberg
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: Guixin Liu @ 2024-12-09 1:53 UTC (permalink / raw)
To: Keith Busch, Jens Axboe, Christoph Hellwig, Sagi Grimberg,
Chaitanya Kulkarni
Cc: linux-nvme
In some scenarios, some multipath software setup places the
REQ_FAILFAST_DEV flag on I/O to prevent retries and immediately
switch to other paths for issuing I/O commands. This will reflect
on the NVMe read and write commands with the limited retry flag.
However, the current NVMe target side does not handle the limited
retry flag, and the target's underlying driver still retries the
I/O. This will result in the I/O not being quickly switched to
other paths, ultimately leading to increased I/O latency.
When the nvme target receive an rw command with limited retry flag,
handle it in block backend by setting the REQ_FAILFAST_DEV flag to
bio.
Signed-off-by: Guixin Liu <kanie@linux.alibaba.com>
Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
Changes from v2 to v3:
- Add the rb tag from Christoph, thanks.
Changes from v1 to v2:
- Add details to commit body(Christoph).
- Add the rb tag from Chaitanya, thanks.
drivers/nvme/target/io-cmd-bdev.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/nvme/target/io-cmd-bdev.c b/drivers/nvme/target/io-cmd-bdev.c
index 0bda83d0fc3e..6380b60fd490 100644
--- a/drivers/nvme/target/io-cmd-bdev.c
+++ b/drivers/nvme/target/io-cmd-bdev.c
@@ -272,6 +272,9 @@ static void nvmet_bdev_execute_rw(struct nvmet_req *req)
iter_flags = SG_MITER_FROM_SG;
}
+ if (req->cmd->rw.control & NVME_RW_LR)
+ opf |= REQ_FAILFAST_DEV;
+
if (is_pci_p2pdma_page(sg_page(req->sg)))
opf |= REQ_NOMERGE;
--
2.43.0
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH v3] nvmet: handle rw's limited retry flag
2024-12-09 1:53 [PATCH v3] nvmet: handle rw's limited retry flag Guixin Liu
@ 2024-12-24 11:30 ` Sagi Grimberg
2025-01-02 1:50 ` Guixin Liu
2025-01-07 16:49 ` Keith Busch
2 siblings, 0 replies; 4+ messages in thread
From: Sagi Grimberg @ 2024-12-24 11:30 UTC (permalink / raw)
To: Guixin Liu, Keith Busch, Jens Axboe, Christoph Hellwig,
Chaitanya Kulkarni
Cc: linux-nvme
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v3] nvmet: handle rw's limited retry flag
2024-12-09 1:53 [PATCH v3] nvmet: handle rw's limited retry flag Guixin Liu
2024-12-24 11:30 ` Sagi Grimberg
@ 2025-01-02 1:50 ` Guixin Liu
2025-01-07 16:49 ` Keith Busch
2 siblings, 0 replies; 4+ messages in thread
From: Guixin Liu @ 2025-01-02 1:50 UTC (permalink / raw)
To: Keith Busch
Cc: linux-nvme, Jens Axboe, Christoph Hellwig, Chaitanya Kulkarni,
Sagi Grimberg
Hi Keith,
Could you plz apply this patch?
Best Regards,
Guixin Liu
在 2024/12/9 09:53, Guixin Liu 写道:
> In some scenarios, some multipath software setup places the
> REQ_FAILFAST_DEV flag on I/O to prevent retries and immediately
> switch to other paths for issuing I/O commands. This will reflect
> on the NVMe read and write commands with the limited retry flag.
>
> However, the current NVMe target side does not handle the limited
> retry flag, and the target's underlying driver still retries the
> I/O. This will result in the I/O not being quickly switched to
> other paths, ultimately leading to increased I/O latency.
>
> When the nvme target receive an rw command with limited retry flag,
> handle it in block backend by setting the REQ_FAILFAST_DEV flag to
> bio.
>
> Signed-off-by: Guixin Liu <kanie@linux.alibaba.com>
> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> ---
> Changes from v2 to v3:
> - Add the rb tag from Christoph, thanks.
>
> Changes from v1 to v2:
> - Add details to commit body(Christoph).
> - Add the rb tag from Chaitanya, thanks.
>
> drivers/nvme/target/io-cmd-bdev.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/nvme/target/io-cmd-bdev.c b/drivers/nvme/target/io-cmd-bdev.c
> index 0bda83d0fc3e..6380b60fd490 100644
> --- a/drivers/nvme/target/io-cmd-bdev.c
> +++ b/drivers/nvme/target/io-cmd-bdev.c
> @@ -272,6 +272,9 @@ static void nvmet_bdev_execute_rw(struct nvmet_req *req)
> iter_flags = SG_MITER_FROM_SG;
> }
>
> + if (req->cmd->rw.control & NVME_RW_LR)
> + opf |= REQ_FAILFAST_DEV;
> +
> if (is_pci_p2pdma_page(sg_page(req->sg)))
> opf |= REQ_NOMERGE;
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v3] nvmet: handle rw's limited retry flag
2024-12-09 1:53 [PATCH v3] nvmet: handle rw's limited retry flag Guixin Liu
2024-12-24 11:30 ` Sagi Grimberg
2025-01-02 1:50 ` Guixin Liu
@ 2025-01-07 16:49 ` Keith Busch
2 siblings, 0 replies; 4+ messages in thread
From: Keith Busch @ 2025-01-07 16:49 UTC (permalink / raw)
To: Guixin Liu
Cc: Jens Axboe, Christoph Hellwig, Sagi Grimberg, Chaitanya Kulkarni,
linux-nvme
On Mon, Dec 09, 2024 at 09:53:44AM +0800, Guixin Liu wrote:
> In some scenarios, some multipath software setup places the
> REQ_FAILFAST_DEV flag on I/O to prevent retries and immediately
> switch to other paths for issuing I/O commands. This will reflect
> on the NVMe read and write commands with the limited retry flag.
>
> However, the current NVMe target side does not handle the limited
> retry flag, and the target's underlying driver still retries the
> I/O. This will result in the I/O not being quickly switched to
> other paths, ultimately leading to increased I/O latency.
>
> When the nvme target receive an rw command with limited retry flag,
> handle it in block backend by setting the REQ_FAILFAST_DEV flag to
> bio.
Thanks, applied to nvme-6.14.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-01-07 17:13 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-12-09 1:53 [PATCH v3] nvmet: handle rw's limited retry flag Guixin Liu
2024-12-24 11:30 ` Sagi Grimberg
2025-01-02 1:50 ` Guixin Liu
2025-01-07 16:49 ` Keith Busch
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox