Re: [PATCH] nvme: Add support for ACRE Command Interrupted status

["Meneghini, John" <John.Meneghini@netapp.com>]

On 11/26/19, 11:32 AM, "Hannes Reinecke" <hare@suse.de> 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;
    >> +    case NVME_SC_COMMAND_INTERRUPTED:
    >> +            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?

/John
 

_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme