[PATCH] nvme-core: update NS Attr Changed AEN handling for ANA group

Knight, Frederick Frederick.Knight at netapp.com
Tue Dec 8 14:13:00 EST 2020


Setting up a new ANA Group does NOT cause a transition from <UNKNOWN state> to <some known state>.  The establishment of initial state is NOT a change of state as defined in section 8.20.3.6.

An ANA AEN is prohibited if the ANA change is due to the creation of a namespace.

If you want to change the text from the original requirements and design, then please bring a TPAR to make that change.

	Fred

-----Original Message-----
From: Keith Busch <kbusch at kernel.org> 
Sent: Tuesday, December 8, 2020 1:35 PM
To: Knight, Frederick <Frederick.Knight at netapp.com>
Cc: hch at lst.de; Meneghini, John <John.Meneghini at netapp.com>; George, Martin <Martin.George at netapp.com>; linux-nvme at lists.infradead.org; sagi at grimberg.me; Hannes Reinecke <hare at suse.com>
Subject: Re: [PATCH] nvme-core: update NS Attr Changed AEN handling for ANA group

NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.




On Tue, Dec 08, 2020 at 06:15:08PM +0000, Knight, Frederick wrote:
> We can't send the AEN if we create the ANA Group before creating the namespace - because there is no attached NS to which we can send the AER.  And, we can't create a namespace in an ANA group unless the ANA group already exists.
>
> OK, here is the text you are quoting:
> 8.20.3.6      Asymmetric Namespace Access Change Notifications
> If Asymmetric Namespace Access Change Notices are enabled (refer to section 5.21.1.11) on a controller, then an Asymmetric Namespace Access Change Notice shall be sent by the controllers where the change occurred:
> a)    if an ANA Group Identifier (refer to Figure 251) changes;
> b)    if an asymmetric namespace access state transition fails (e.g., a transition begins, but does not complete and the controller returns to the state that existed before the transition began); or
> c)    upon entry to the following ANA states:
> •     ANA Optimized State;
> •     ANA Non-Optimized State;
> •     ANA Inaccessible State; and
> •     ANA Persistent Loss State.
>
> So, what you're saying is that storage determining the initial state 
> is a TRANSITION.  So that would also mean that after every connection, 
> you would get a FLOOD of ANA Changed AENs as we discover the initial 
> state of each ANA group, and TRANSITION that group from <unknown> to 
> optimized state (or one of those 4 states).
>
> That honestly makes no sense.  You really want all those AENs every 
> time you connect to a new controller?

Why on would you get a flood of ANA on a connection? You haven't even got an outstanding AEN command to respond to upon controller connection, nor has the AEN feature configuration been set on connection either.
The initial reading of the log clears all AEN events of that type with a single read anyway, so you don't send any AEN responses for this.

Now, if the host were to enable ANA events and send an AEN before it reads the log, then sure, you might send a single AEN response to notify the host that the ANA log has data the host hasn't read yet.

> Discovery by the host of a new namespace should be the same if it 
> happens at boot, or it happens later when a new namespace is 
> discovered.  It seems like you're asking for 2 different discovery 
> processes.  For some period after a new connection, you don't want the 
> AENs telling you the ANA group entered its initial state, but after 
> that time is up, then you DO want AENs to tell you when an ANA group 
> enters its initial state.

The event is latched by the host reading the log with RAE bit. This isn't some arbitrary temporal descision.

> The text never mentions anything about changes to "Number of ANA Group 
> Descriptors" field and any relationship with the AEN, so I have no 
> idea where you're getting that from.  The text does explicitly say 
> that if the ANA changes was due to the creation of a namespace - if 
> the ANA log pages changes because of a namespace being created, then 
> there is NO AEN for that change.

I'm only saying the text says a controller that has events enabled affected from a group entering an ANA state "shall" send an event. A controller with a group having no state to now having a state certainly sounds like that controller has an ANA group entering a state.

> A controller shall not send this event if:
> a)    the change is due to the creation of a namespace (refer to section 5.20); or
> b)    the change is due to the deletion of a namespace (refer to section 5.20),

The text also says the controller shall send the event when a group enters a state. There are no exceptions listed in that section.


More information about the Linux-nvme mailing list