From: Mike Snitzer <snitzer@redhat.com>
To: Hannes Reinecke <hare@suse.de>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-nvme@lists.infradead.org, linux-block@vger.kernel.org,
dm-devel@redhat.com, Chao Leng <lengchao@huawei.com>,
Christoph Hellwig <hch@lst.de>
Subject: Re: [dm-devel] [PATCH v2 2/4] nvme: allow local retry for requests with REQ_FAILFAST_TRANSPORT set
Date: Fri, 16 Apr 2021 10:53:40 -0400 [thread overview]
Message-ID: <20210416145340.GB16047@redhat.com> (raw)
In-Reply-To: <da184561-2c97-5807-5c5b-9cc6593693c6@suse.de>
On Fri, Apr 16 2021 at 10:01am -0400,
Hannes Reinecke <hare@suse.de> wrote:
> On 4/16/21 1:15 AM, Mike Snitzer wrote:
> > From: Chao Leng <lengchao@huawei.com>
> >
> > REQ_FAILFAST_TRANSPORT was designed for SCSI, because the 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
> > retried locally, path related error is handled by multipath.
> >
> > Signed-off-by: Chao Leng <lengchao@huawei.com>
> > [snitzer: edited header for grammar and clarity, also added code comment]
> > Signed-off-by: Mike Snitzer <snitzer@redhat.com>
> > ---
> > drivers/nvme/host/core.c | 9 ++++++++-
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> > index 540d6fd8ffef..4134cf3c7e48 100644
> > --- a/drivers/nvme/host/core.c
> > +++ b/drivers/nvme/host/core.c
> > @@ -306,7 +306,14 @@ static inline enum nvme_disposition nvme_decide_disposition(struct request *req)
> > 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;
> >
> Huh?
>
> #define blk_noretry_request(rq) \
> ((rq)->cmd_flags & (REQ_FAILFAST_DEV|REQ_FAILFAST_TRANSPORT| \
> REQ_FAILFAST_DRIVER))
>
> making the only _actual_ change in your patch _not_ evaluating the
> REQ_FAILFAST_DRIVER, which incidentally is only used by the NVMe core.
No, not sure how you got there. I'd have thought the 5 references to
"REQ_FAILFAST_TRANSPORT" would've been sufficient ;)
This patch makes it so requests marked with REQ_FAILFAST_TRANSPORT are
allowed to use NVMe's local retry (that is required for non-transport
errors).
> So what is it you're trying to solve?
What the patch header, code and code comment detail.
Mike
--
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: Hannes Reinecke <hare@suse.de>
Cc: Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
dm-devel@redhat.com, linux-block@vger.kernel.org,
linux-nvme@lists.infradead.org, Chao Leng <lengchao@huawei.com>
Subject: Re: [PATCH v2 2/4] nvme: allow local retry for requests with REQ_FAILFAST_TRANSPORT set
Date: Fri, 16 Apr 2021 10:53:40 -0400 [thread overview]
Message-ID: <20210416145340.GB16047@redhat.com> (raw)
In-Reply-To: <da184561-2c97-5807-5c5b-9cc6593693c6@suse.de>
On Fri, Apr 16 2021 at 10:01am -0400,
Hannes Reinecke <hare@suse.de> wrote:
> On 4/16/21 1:15 AM, Mike Snitzer wrote:
> > From: Chao Leng <lengchao@huawei.com>
> >
> > REQ_FAILFAST_TRANSPORT was designed for SCSI, because the 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
> > retried locally, path related error is handled by multipath.
> >
> > Signed-off-by: Chao Leng <lengchao@huawei.com>
> > [snitzer: edited header for grammar and clarity, also added code comment]
> > Signed-off-by: Mike Snitzer <snitzer@redhat.com>
> > ---
> > drivers/nvme/host/core.c | 9 ++++++++-
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> > index 540d6fd8ffef..4134cf3c7e48 100644
> > --- a/drivers/nvme/host/core.c
> > +++ b/drivers/nvme/host/core.c
> > @@ -306,7 +306,14 @@ static inline enum nvme_disposition nvme_decide_disposition(struct request *req)
> > 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;
> >
> Huh?
>
> #define blk_noretry_request(rq) \
> ((rq)->cmd_flags & (REQ_FAILFAST_DEV|REQ_FAILFAST_TRANSPORT| \
> REQ_FAILFAST_DRIVER))
>
> making the only _actual_ change in your patch _not_ evaluating the
> REQ_FAILFAST_DRIVER, which incidentally is only used by the NVMe core.
No, not sure how you got there. I'd have thought the 5 references to
"REQ_FAILFAST_TRANSPORT" would've been sufficient ;)
This patch makes it so requests marked with REQ_FAILFAST_TRANSPORT are
allowed to use NVMe's local retry (that is required for non-transport
errors).
> So what is it you're trying to solve?
What the patch header, code and code comment detail.
Mike
WARNING: multiple messages have this Message-ID (diff)
From: Mike Snitzer <snitzer@redhat.com>
To: Hannes Reinecke <hare@suse.de>
Cc: Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
dm-devel@redhat.com, linux-block@vger.kernel.org,
linux-nvme@lists.infradead.org, Chao Leng <lengchao@huawei.com>
Subject: Re: [PATCH v2 2/4] nvme: allow local retry for requests with REQ_FAILFAST_TRANSPORT set
Date: Fri, 16 Apr 2021 10:53:40 -0400 [thread overview]
Message-ID: <20210416145340.GB16047@redhat.com> (raw)
In-Reply-To: <da184561-2c97-5807-5c5b-9cc6593693c6@suse.de>
On Fri, Apr 16 2021 at 10:01am -0400,
Hannes Reinecke <hare@suse.de> wrote:
> On 4/16/21 1:15 AM, Mike Snitzer wrote:
> > From: Chao Leng <lengchao@huawei.com>
> >
> > REQ_FAILFAST_TRANSPORT was designed for SCSI, because the 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
> > retried locally, path related error is handled by multipath.
> >
> > Signed-off-by: Chao Leng <lengchao@huawei.com>
> > [snitzer: edited header for grammar and clarity, also added code comment]
> > Signed-off-by: Mike Snitzer <snitzer@redhat.com>
> > ---
> > drivers/nvme/host/core.c | 9 ++++++++-
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> > index 540d6fd8ffef..4134cf3c7e48 100644
> > --- a/drivers/nvme/host/core.c
> > +++ b/drivers/nvme/host/core.c
> > @@ -306,7 +306,14 @@ static inline enum nvme_disposition nvme_decide_disposition(struct request *req)
> > 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;
> >
> Huh?
>
> #define blk_noretry_request(rq) \
> ((rq)->cmd_flags & (REQ_FAILFAST_DEV|REQ_FAILFAST_TRANSPORT| \
> REQ_FAILFAST_DRIVER))
>
> making the only _actual_ change in your patch _not_ evaluating the
> REQ_FAILFAST_DRIVER, which incidentally is only used by the NVMe core.
No, not sure how you got there. I'd have thought the 5 references to
"REQ_FAILFAST_TRANSPORT" would've been sufficient ;)
This patch makes it so requests marked with REQ_FAILFAST_TRANSPORT are
allowed to use NVMe's local retry (that is required for non-transport
errors).
> So what is it you're trying to solve?
What the patch header, code and code comment detail.
Mike
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2021-04-16 14:54 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-15 23:15 [dm-devel] [PATCH v2 0/4] nvme: improve error handling and ana_state to work well with dm-multipath Mike Snitzer
2021-04-15 23:15 ` Mike Snitzer
2021-04-15 23:15 ` Mike Snitzer
2021-04-15 23:15 ` [dm-devel] [PATCH v2 1/4] nvme: return BLK_STS_DO_NOT_RETRY if the DNR bit is set Mike Snitzer
2021-04-15 23:15 ` Mike Snitzer
2021-04-15 23:15 ` Mike Snitzer
2021-04-15 23:48 ` [dm-devel] " Chaitanya Kulkarni
2021-04-15 23:48 ` Chaitanya Kulkarni
2021-04-15 23:48 ` Chaitanya Kulkarni
2021-04-16 13:51 ` [dm-devel] " Hannes Reinecke
2021-04-16 13:51 ` Hannes Reinecke
2021-04-16 13:51 ` Hannes Reinecke
2021-04-15 23:15 ` [dm-devel] [PATCH v2 2/4] nvme: allow local retry for requests with REQ_FAILFAST_TRANSPORT set Mike Snitzer
2021-04-15 23:15 ` Mike Snitzer
2021-04-15 23:15 ` Mike Snitzer
2021-04-16 14:01 ` [dm-devel] " Hannes Reinecke
2021-04-16 14:01 ` Hannes Reinecke
2021-04-16 14:01 ` Hannes Reinecke
2021-04-16 14:53 ` Mike Snitzer [this message]
2021-04-16 14:53 ` Mike Snitzer
2021-04-16 14:53 ` Mike Snitzer
2021-04-16 15:20 ` [dm-devel] " Hannes Reinecke
2021-04-16 15:20 ` Hannes Reinecke
2021-04-16 15:20 ` Hannes Reinecke
2021-04-16 15:32 ` [dm-devel] " Mike Snitzer
2021-04-16 15:32 ` Mike Snitzer
2021-04-16 15:32 ` Mike Snitzer
2021-04-15 23:15 ` [dm-devel] [PATCH v2 3/4] nvme: introduce FAILUP handling for REQ_FAILFAST_TRANSPORT Mike Snitzer
2021-04-15 23:15 ` Mike Snitzer
2021-04-15 23:15 ` Mike Snitzer
2021-04-16 14:07 ` [dm-devel] " Hannes Reinecke
2021-04-16 14:07 ` Hannes Reinecke
2021-04-16 14:07 ` Hannes Reinecke
2021-04-16 15:03 ` [dm-devel] " Mike Snitzer
2021-04-16 15:03 ` Mike Snitzer
2021-04-16 15:03 ` Mike Snitzer
2021-04-16 16:23 ` [dm-devel] " Hannes Reinecke
2021-04-16 16:23 ` Hannes Reinecke
2021-04-16 16:23 ` Hannes Reinecke
2021-04-16 20:03 ` [dm-devel] " Ewan D. Milne
2021-04-16 20:03 ` Ewan D. Milne
2021-04-16 20:03 ` Ewan D. Milne
2021-04-16 20:52 ` Ewan D. Milne
2021-04-16 20:52 ` Ewan D. Milne
2021-04-16 20:52 ` Ewan D. Milne
2021-04-16 21:44 ` [dm-devel] " Mike Snitzer
2021-04-16 21:44 ` Mike Snitzer
2021-04-16 21:44 ` Mike Snitzer
2021-04-15 23:15 ` [dm-devel] [PATCH v2 4/4] nvme: decouple basic ANA log page re-read support from native multipathing Mike Snitzer
2021-04-15 23:15 ` Mike Snitzer
2021-04-15 23:15 ` Mike Snitzer
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=20210416145340.GB16047@redhat.com \
--to=snitzer@redhat.com \
--cc=axboe@kernel.dk \
--cc=dm-devel@redhat.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=lengchao@huawei.com \
--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.