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

[Meneghini, John]

On 11/20/20, 4:49 AM, "Linux-nvme on behalf of hch at lst.de" <linux-nvme-bounces at lists.infradead.org on behalf of hch at 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
    Linux-nvme at lists.infradead.org
    http://lists.infradead.org/mailman/listinfo/linux-nvme