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

["Knight, Frederick" <Frederick.Knight@netapp.com>]

Here is what I would expect to:
A) create a namespace in existing ANA group:
	1) NS Attribute Changed AEN (because the NS List returned has changed)
	2) Host gets the list - discovers the NEW NS
		Including: Determine which ANAGRPID that NS belongs to (for which the host already knows the state).

B) create a namespace in a NEW ANA group
	1) NS Attribute Changed AEN (because the NS List returned has changed)
	2) Host gets the list - discovers the new NS
		Including: Determine there is a BRAND NEW ANAGRPID that the host knows NOTHING about.
		Since the host knows NOTHING about that ANAGRPID, it seems the host should go look.

It seems that the existing text says there is NO ANA AEN for a "new" namespace.  John quoted the text:

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),
as the Namespace Attribute Changed event is sent for these changes.

Christoph claims that the ANA AEN should be send before the NS Attribute Changed AEN.  And, that could be true for an ANAGRPID that changed (although, I don't see text describing any precedence or order requirements for delivery of AENs), but the NS creation case is explicitly excluded.  FWIW – Christoph was one of the people that requested this exclusion to prevent spaming the host with multiple AENs for the same event (a NS create).

	Fred

-----Original Message-----
From: Meneghini, John <John.Meneghini@netapp.com> 
Sent: Monday, November 23, 2020 9:36 AM
To: hch@lst.de; George, Martin <Martin.George@netapp.com>
Cc: kbusch@kernel.org; linux-nvme@lists.infradead.org; sagi@grimberg.me; Meneghini, John <John.Meneghini@netapp.com>; Knight, Frederick <Frederick.Knight@netapp.com>; Hannes Reinecke <hare@suse.com>
Subject: Re: [PATCH] nvme-core: update NS Attr Changed AEN handling for ANA group

On 11/20/20, 4:49 AM, "Linux-nvme on behalf of mailto:hch@lst.de" <mailto:linux-nvme-bounces@lists.infradead.org on behalf of hch@lst.de> wrote:

    On Wed, Nov 18, 2020 at 08:09:43PM +0000, George, Martin wrote:
    > > How can the namespace reference an ANA group that we haven't been
    > > notified about using the NVME_AEN_CFG_ANA_CHANGE AEN before?
    >
    > Well, I think that could be possible for a newly created namespace,
    > which happens to belong to a new ANA group. To quote the 1.4 spec in
    > context of Asymmetric Namespace Access Change under the Asynchronous
    > Event Information - Notice (Figure 147):
    >
    > "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),
    > as the Namespace Attribute Changed event is sent for these changes."
    >
    > So it looks the NVME_AEN_CFG_ANA_CHANGE AEN is not required here for
    > such cases, but instead the NVME_AEN_CFG_NS_ATTR AEN would do.

    For the newly created namespace to beong to a newly created ANA group
    the controller first needs to send NVME_AEN_CFG_ANA_CHANGE to announce
    the ANA group, it then send NVME_AEN_CFG_NS_ATTR to announce the
    new namespaces.  But the new namespace can't reference an ANA group
    that didn't exist, that is a separate event.

I remember discussing this at length when we wrote this text for TP-4004.   We explicitly restricted  NVME_AEN_CFG_ANA_CHANGE AENs to ANA state change events, and ANAGRPID change events.  And we restricted NVME_AEN_CFG_NS_ATTR AENs so that ANA state/ANAGRPID change events would not generate an NVME_AEN_CFG_NS_ATTR.  We did this so as to avoid duplicate AENs. The discovery of new ANAGRP IDs was always supposed to take place as a part of namespace discovery.  

/John

Figure 49: Asynchronous Event Information - Notice

Namespace Attribute Changed:
...
A controller shall not send this event if:
   a) Namespace Utilization (refer to Figure 114) has changed, as this is a frequent event that does not require action by the host;
   b) the ANAGRPID field (refer to Figure 114) has changed; or
   c) capacity information (i.e., the NUSE field and the NVMCAP field) returned in the Identify Namespace Data Structure (refer to Figure 114) changed as a result of an ANA state change.
...

Asymmetric Namespace Access Change: 

The Asymmetric Namespace Access information (refer to section 5.14.1.12) related to an ANA Group that contains namespaces attached to this controller has changed (e.g., an ANA state has changed, an ANAGRPID has changed). The current Asymmetric Namespace Access information for attached namespaces is indicated in the Asymmetric Namespace Access log page (refer to section 5.14.1.12). To clear this event, the host issues a Get Log Page with Retain Asynchronous Event cleared to ‘0’ for the Asymmetric Namespace Access Log.

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), as the Namespace Attribute Changed event is sent for these changes.

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


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