archive mirror
 help / color / mirror / Atom feed
From: "Meneghini, John" <>
To: Hannes Reinecke <>, Keith Busch <>
Cc: Jen Axboe <>, Sagi Grimberg <>,
	"" <>,
	"" <>,
	Christoph Hellwig <>,
	"Knight, Frederick" <>,
	"Meneghini, John" <>
Subject: Re: [PATCH] nvme: Add support for ACRE Command Interrupted status
Date: Wed, 27 Nov 2019 17:17:40 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 11/26/19, 11:32 AM, "Hannes Reinecke" <> wrote:
    On 11/26/19 5:05 PM, Keith Busch wrote:
    > [cc'ing linux-block, Jens]
    > On Tue, Nov 26, 2019 at 02:36:50PM +0100, Hannes Reinecke wrote:
    >> This patch fixes a bug in nvme_complete_rq logic introduced by
    >> Enhanced Command Retry code. According to TP-4033 the controller
    >> only sets CDR when the Command Interrupted status is returned.
    >> The current code interprets Command Interrupted status as a
    >> BLK_STS_IOERR, which results in a controller reset if
    >> REQ_NVME_MPATH is set.
    > I see that Command Interrupted status requires ACRE enabled, but I don't
    > see the TP saying that the CQE CRD fields are used only with that status
    > code. I'm pretty sure I've seen it used for Namespace Not Ready status
    > as well. That would also fail MPATH for the same reason as this new
    > status...

    > No, true, CRD is not directly related to 'command interrupted'.
    > According to the powers that be CRD evaluation is depending on the ACRE
    > setting (and hence should be evaluated whenever a command needs to be
    > retried), but 'command interrupted' will only be returned if ACRE is
    > enabled.

Yes, we had a long debate about this with Fred.  CRD does not require the Command
Interrupted status, but Command Interrupted requires CRD.

   > Consequently, whenever you get a 'command interrupted' you need to check
   > the CRD setting to figure out the delay.

Whenever _any_ CQE sets CRD and clears DNR the host is required to implement
the delay.  The requirement is on the controller to always set CRD when Command
Interrupted status is returned.

Also, the host is required to handle Command Interrupted if it enables ACRE.

But then that's the bug....

    >> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
    >> index 108f60b46804..752a40daf2b3 100644
    >> --- a/drivers/nvme/host/core.c
    >> +++ b/drivers/nvme/host/core.c
    >> @@ -201,6 +201,8 @@ static blk_status_t nvme_error_status(u16 status)
    >>      switch (status & 0x7ff) {
    >>      case NVME_SC_SUCCESS:
    >>              return BLK_STS_OK;
    >> +            return BLK_STS_RESOURCE;
    >>      case NVME_SC_CAP_EXCEEDED:
    >>              return BLK_STS_NOSPC;
    >>      case NVME_SC_LBA_RANGE:
    >> diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
    >> index d688b96d1d63..3a0d84528325 100644
    >> --- a/include/linux/blk_types.h
    >> +++ b/include/linux/blk_types.h
    >> @@ -84,6 +84,7 @@ static inline bool blk_path_error(blk_status_t error)
    >>      case BLK_STS_NEXUS:
    >>      case BLK_STS_MEDIUM:
    >>      case BLK_STS_PROTECTION:
    >> +    case BLK_STS_RESOURCE:
    >>              return false;
    >>      }
    > I agree we need to make this status a non-path error, but we at least
    > need an Ack from Jens or have this patch go through linux-block if we're
    > changing BLK_STS_RESOURCE to mean a non-path error.
    > Alternatively we can define a new return value, if we shouldn't re-use
    > existing ones. Either way I'm fine with.
It seems to me that the block layer is never going to see BLK_STS_RESOURCE unless 
nvme_req(req)->retries run out... and at that point it doesn't matter, does it?

What's the result if the controller returns Command Interrupted status
for the same request repeatedly and we returning BLK_STS_RESOURCE
after nvme_max_retries?


linux-nvme mailing list

      reply	other threads:[~2019-11-27 17:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-26 13:36 [PATCH] nvme: Add support for ACRE Command Interrupted status Hannes Reinecke
2019-11-26 14:48 ` George, Martin
2019-11-26 16:05 ` Keith Busch
2019-11-26 16:24   ` Christoph Hellwig
2019-11-27 15:29     ` Meneghini, John
2019-11-27 19:08       ` Keith Busch
2019-11-27 19:22         ` Meneghini, John
2019-11-26 16:32   ` Hannes Reinecke
2019-11-27 17:17     ` Meneghini, John [this message]

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \

* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).