From: Mike Snitzer <snitzer@redhat.com>
To: Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>
Cc: linux-block@vger.kernel.org, dm-devel@redhat.com,
linux-nvme@lists.infradead.org
Subject: [dm-devel] nvme: allow retry for requests with REQ_FAILFAST_TRANSPORT set
Date: Thu, 15 Apr 2021 19:11:26 -0400 [thread overview]
Message-ID: <20210415231126.8746-4-snitzer@redhat.com> (raw)
In-Reply-To: <20210415231126.8746-1-snitzer@redhat.com>
BZ: 1948690
Upstream Status: RHEL-only
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
rhel-8.git commit 7dadadb072515f243868e6fe2f7e9c97fd3516c9
Author: Mike Snitzer <snitzer@redhat.com>
Date: Tue Aug 25 21:52:48 2020 -0400
[nvme] nvme: allow retry for requests with REQ_FAILFAST_TRANSPORT set
Message-id: <20200825215248.2291-11-snitzer@redhat.com>
Patchwork-id: 325180
Patchwork-instance: patchwork
O-Subject: [RHEL8.3 PATCH 10/10] nvme: allow retry for requests with REQ_FAILFAST_TRANSPORT set
Bugzilla: 1843515
RH-Acked-by: David Milburn <dmilburn@redhat.com>
RH-Acked-by: Gopal Tiwari <gtiwari@redhat.com>
RH-Acked-by: Ewan Milne <emilne@redhat.com>
BZ: 1843515
Upstream Status: RHEL-only
Based on patch that was proposed upstream but ultimately rejected, see:
https://www.spinics.net/lists/linux-block/msg57490.html
I'd have made this change even if this wasn't already posted obviously,
but I figured I'd give proper attribution due to their public post with
the same code change.
Author: Chao Leng <lengchao@huawei.com>
Date: Wed Aug 12 16:18:55 2020 +0800
nvme: allow retry for requests with REQ_FAILFAST_TRANSPORT set
REQ_FAILFAST_TRANSPORT may be designed for SCSI, because SCSI protocol
does not define the local retry mechanism. SCSI implements a fuzzy
local retry mechanism, so REQ_FAILFAST_TRANSPORT is needed to allow
higher-level multipathing software to perform failover/retry.
NVMe is different with SCSI about this. It defines a local retry
mechanism and path error codes, so NVMe should retry local for non
path error. If path related error, whether to retry and how to retry
is still determined by higher-level multipathing's failover.
Unlike SCSI, NVMe shouldn't prevent retry if REQ_FAILFAST_TRANSPORT
because NVMe's local retry is needed -- as is NVMe specific logic to
categorize whether an error is path related.
In this way, the mechanism of NVMe multipath or other multipath are
now equivalent. The mechanism is: non path related error will be
retry local, path related error is handled by multipath.
Signed-off-by: Chao Leng <lengchao@huawei.com>
[snitzer: edited header for grammar and to make clearer]
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Frantisek Hrbata <fhrbata@redhat.com>
---
drivers/nvme/host/core.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
Index: linux-rhel9/drivers/nvme/host/core.c
===================================================================
--- linux-rhel9.orig/drivers/nvme/host/core.c
+++ linux-rhel9/drivers/nvme/host/core.c
@@ -306,7 +306,14 @@ static inline enum nvme_disposition nvme
if (likely(nvme_req(req)->status == 0))
return COMPLETE;
- if (blk_noretry_request(req) ||
+ /*
+ * REQ_FAILFAST_TRANSPORT is set by upper layer software that
+ * handles multipathing. Unlike SCSI, NVMe's error handling was
+ * specifically designed to handle local retry for non-path errors.
+ * As such, allow NVMe's local retry mechanism to be used for
+ * requests marked with REQ_FAILFAST_TRANSPORT.
+ */
+ if ((req->cmd_flags & (REQ_FAILFAST_DEV | REQ_FAILFAST_DRIVER)) ||
(nvme_req(req)->status & NVME_SC_DNR) ||
nvme_req(req)->retries >= nvme_max_retries)
return COMPLETE;
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
WARNING: multiple messages have this Message-ID (diff)
From: Mike Snitzer <snitzer@redhat.com>
To: Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>
Cc: dm-devel@redhat.com, linux-block@vger.kernel.org,
linux-nvme@lists.infradead.org
Subject: nvme: allow retry for requests with REQ_FAILFAST_TRANSPORT set
Date: Thu, 15 Apr 2021 19:11:26 -0400 [thread overview]
Message-ID: <20210415231126.8746-4-snitzer@redhat.com> (raw)
In-Reply-To: <20210415231126.8746-1-snitzer@redhat.com>
BZ: 1948690
Upstream Status: RHEL-only
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
rhel-8.git commit 7dadadb072515f243868e6fe2f7e9c97fd3516c9
Author: Mike Snitzer <snitzer@redhat.com>
Date: Tue Aug 25 21:52:48 2020 -0400
[nvme] nvme: allow retry for requests with REQ_FAILFAST_TRANSPORT set
Message-id: <20200825215248.2291-11-snitzer@redhat.com>
Patchwork-id: 325180
Patchwork-instance: patchwork
O-Subject: [RHEL8.3 PATCH 10/10] nvme: allow retry for requests with REQ_FAILFAST_TRANSPORT set
Bugzilla: 1843515
RH-Acked-by: David Milburn <dmilburn@redhat.com>
RH-Acked-by: Gopal Tiwari <gtiwari@redhat.com>
RH-Acked-by: Ewan Milne <emilne@redhat.com>
BZ: 1843515
Upstream Status: RHEL-only
Based on patch that was proposed upstream but ultimately rejected, see:
https://www.spinics.net/lists/linux-block/msg57490.html
I'd have made this change even if this wasn't already posted obviously,
but I figured I'd give proper attribution due to their public post with
the same code change.
Author: Chao Leng <lengchao@huawei.com>
Date: Wed Aug 12 16:18:55 2020 +0800
nvme: allow retry for requests with REQ_FAILFAST_TRANSPORT set
REQ_FAILFAST_TRANSPORT may be designed for SCSI, because SCSI protocol
does not define the local retry mechanism. SCSI implements a fuzzy
local retry mechanism, so REQ_FAILFAST_TRANSPORT is needed to allow
higher-level multipathing software to perform failover/retry.
NVMe is different with SCSI about this. It defines a local retry
mechanism and path error codes, so NVMe should retry local for non
path error. If path related error, whether to retry and how to retry
is still determined by higher-level multipathing's failover.
Unlike SCSI, NVMe shouldn't prevent retry if REQ_FAILFAST_TRANSPORT
because NVMe's local retry is needed -- as is NVMe specific logic to
categorize whether an error is path related.
In this way, the mechanism of NVMe multipath or other multipath are
now equivalent. The mechanism is: non path related error will be
retry local, path related error is handled by multipath.
Signed-off-by: Chao Leng <lengchao@huawei.com>
[snitzer: edited header for grammar and to make clearer]
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Frantisek Hrbata <fhrbata@redhat.com>
---
drivers/nvme/host/core.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
Index: linux-rhel9/drivers/nvme/host/core.c
===================================================================
--- linux-rhel9.orig/drivers/nvme/host/core.c
+++ linux-rhel9/drivers/nvme/host/core.c
@@ -306,7 +306,14 @@ static inline enum nvme_disposition nvme
if (likely(nvme_req(req)->status == 0))
return COMPLETE;
- if (blk_noretry_request(req) ||
+ /*
+ * REQ_FAILFAST_TRANSPORT is set by upper layer software that
+ * handles multipathing. Unlike SCSI, NVMe's error handling was
+ * specifically designed to handle local retry for non-path errors.
+ * As such, allow NVMe's local retry mechanism to be used for
+ * requests marked with REQ_FAILFAST_TRANSPORT.
+ */
+ if ((req->cmd_flags & (REQ_FAILFAST_DEV | REQ_FAILFAST_DRIVER)) ||
(nvme_req(req)->status & NVME_SC_DNR) ||
nvme_req(req)->retries >= nvme_max_retries)
return COMPLETE;
next prev parent reply other threads:[~2021-04-15 23:12 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-15 23:11 [dm-devel] nvme: Return BLK_STS_TARGET if the DNR bit is set Mike Snitzer
2021-04-15 23:11 ` Mike Snitzer
2021-04-15 23:11 ` Mike Snitzer
2021-04-15 23:11 ` [dm-devel] nvme: update failover handling to work with REQ_FAILFAST_TRANSPORT Mike Snitzer
2021-04-15 23:11 ` Mike Snitzer
2021-04-15 23:11 ` [dm-devel] nvme: decouple basic ANA log page re-read support from native multipathing Mike Snitzer
2021-04-15 23:11 ` Mike Snitzer
2021-04-15 23:11 ` Mike Snitzer [this message]
2021-04-15 23:11 ` nvme: allow retry for requests with REQ_FAILFAST_TRANSPORT set Mike Snitzer
2021-04-15 23:18 ` [dm-devel] nvme: Return BLK_STS_TARGET if the DNR bit is set Mike Snitzer
2021-04-15 23:18 ` Mike Snitzer
2021-04-15 23:18 ` Mike Snitzer
2021-04-16 5:58 ` [dm-devel] " Hannes Reinecke
2021-04-16 5:58 ` Hannes Reinecke
2021-04-16 5:58 ` Hannes Reinecke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210415231126.8746-4-snitzer@redhat.com \
--to=snitzer@redhat.com \
--cc=axboe@kernel.dk \
--cc=dm-devel@redhat.com \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.