All of lore.kernel.org
 help / color / mirror / Atom feed
From: willy@linux.intel.com (Matthew Wilcox)
Subject: [PATCH] NVMe: Change how aborts are handled
Date: Wed, 23 Apr 2014 15:55:37 -0400	[thread overview]
Message-ID: <20140423195537.GH13050@linux.intel.com> (raw)
In-Reply-To: <alpine.LRH.2.03.1404170919020.7391@AMR>

On Thu, Apr 17, 2014@09:29:54AM -0600, Keith Busch wrote:
> On Sun, 13 Apr 2014, Matthew Wilcox wrote:
> >+static void abort_cmdid(struct nvme_queue *nvmeq, u16 cmdid)
> >+{
> >+	void *ctx;
> >+	nvme_completion_fn fn;
> >+	static struct nvme_completion cqe = {
> >+		.status = cpu_to_le16(NVME_SC_ABORT_REQ << 1),
> >+	};
> >+
> >+	ctx = cancel_cmdid(nvmeq, cmdid, &fn);
> >+	if (fn(nvmeq, ctx, &cqe))
> >+		clear_bit(cmdid, nvmeq->cmdid_data);
> >+}
> 
> I don't think you want to clear the cmdid bit here. The above internally
> completes the command as failed, but the controller still technically
> owns the cmdid and may still return completion status for it, so we
> don't want to make this cmdid available for reuse just yet.

Ah, right, good point.

> We also don't want to leak the cmdid forever either. The existing method
> will consider the controller being failed and reset it so we can reclaim
> missing cmdids. This new way doesn't appear to reset the controller
> if a command is never returned. At the very least, we probably need to
> delete and recreate the IO queue it's associated with if not go straight
> to the full controller reset.

Yes, resetting the queue will eventually be necessary, and if that
fails we'll need to reset the entire controller.  As I understood the
way things worked before, you gave the controller an extra 60 seconds,
and if it didn't respond in that time, you reset the controller.  We can
use a more explicit timer, perhaps.

> Since the "aborted" flag in nvme_cmd_info adds 4k per queue, maybe we
> can use the lower bits of the "ctx" for this flag instead, and have the
> callbacks mask it off to retrieve the true context? The lower two bits
> should never be in use if I'm not mistaken.

Could do ... I used to do that earlier for indexing into the completion
functions.  Then we needed more than 4, so I gave up on that.  We could
go that path for aborting commands, though I think we'll need to use
two bits to indicate "normal", "abort sent", and "completion received
after abort sent, but abort command not completed yet".

      reply	other threads:[~2014-04-23 19:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-13 17:12 [PATCH] NVMe: Change how aborts are handled Matthew Wilcox
2014-04-14  6:22 ` Matthew Wilcox
2014-04-17 15:29 ` Keith Busch
2014-04-23 19:55   ` Matthew Wilcox [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:
  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=20140423195537.GH13050@linux.intel.com \
    --to=willy@linux.intel.com \
    /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.