From: hch@lst.de (Christoph Hellwig)
Subject: [PATCH 4/4] nvme: start ANATT timer on out-of-order state changes
Date: Thu, 7 Jun 2018 15:46:12 +0200 [thread overview]
Message-ID: <20180607134612.GA15587@lst.de> (raw)
In-Reply-To: <20180607152036.275b0966@pentland.suse.de>
On Thu, Jun 07, 2018@03:20:36PM +0200, Hannes Reinecke wrote:
> Precisely.
> Looking closer, there are not even guarantees within which time any
> target should be sending the AEN.
> So we have to start somewhere when defining a sensible timeframe during
> which we should have received an ANA AEN. And the one timer we already
> have is ANATT, so it looked logical to use that.
ANATT has no relevance here. And more importantly not sending the
AEN until some time later is not going to cause us any grave
consequence - we already notice the non-live states by the status,
so we don't send any I/O.
> Especially due to this paragraph:
> > If no controllers are reporting ANA Optimized state or ANA
> > Non-Optimized state, then a transition may be occurring such that a
> > controller reporting the Inaccessible state may become accessible and
> > the host should retry the command on the controller reporting
> > Inaccessible state for at least ANATT seconds (refer to Figure 109).
>
> which seems to imply to me that we can have an implicit transition on
> the target while reporting the inaccessible state error, and the use of
> ANATT here is indeed applicable.
But we'll still get the AEN. The whole point is the above is that
if we had a queue_if_no_path=0 mode we should not give up before
ANATT.
> This code is essentially error handling.
Chances are this code is going to add more errors than it handles,
as it doesn't follow the spec.
next prev parent reply other threads:[~2018-06-07 13:46 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-07 7:35 [PATCH 0/4] nvme: ANATT handling Hannes Reinecke
2018-06-07 7:35 ` [PATCH 1/4] nvmet: make ANATT configurable Hannes Reinecke
2018-06-07 12:06 ` Christoph Hellwig
2018-06-07 12:42 ` Hannes Reinecke
2018-06-07 13:03 ` Sagi Grimberg
2018-06-07 7:35 ` [PATCH 2/4] nvmet: ANA transition timeout handling Hannes Reinecke
2018-06-07 12:07 ` Christoph Hellwig
2018-06-07 13:31 ` Hannes Reinecke
2018-06-07 13:41 ` Christoph Hellwig
2018-06-07 13:12 ` Sagi Grimberg
2018-06-07 7:35 ` [PATCH 3/4] nvme: " Hannes Reinecke
2018-06-07 12:09 ` Christoph Hellwig
2018-06-07 12:52 ` Hannes Reinecke
2018-06-07 13:11 ` Christoph Hellwig
2018-06-07 13:16 ` Sagi Grimberg
2018-06-07 13:26 ` Christoph Hellwig
2018-06-07 7:35 ` [PATCH 4/4] nvme: start ANATT timer on out-of-order state changes Hannes Reinecke
2018-06-07 12:11 ` Christoph Hellwig
2018-06-07 12:37 ` Hannes Reinecke
2018-06-07 13:10 ` Christoph Hellwig
2018-06-07 13:20 ` Hannes Reinecke
2018-06-07 13:46 ` Christoph Hellwig [this message]
2018-06-07 14:01 ` Hannes Reinecke
2018-06-07 14:22 ` Christoph Hellwig
2018-06-07 15:20 ` Sagi Grimberg
2018-06-07 13:20 ` Sagi Grimberg
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=20180607134612.GA15587@lst.de \
--to=hch@lst.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox