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

[hch at lst.de]

Getting back to this while I'm reviewing the latest competing patches.

On Mon, Nov 23, 2020 at 03:27:35PM +0000, Knight, Frederick wrote:
> 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).

Yes.

> 
> 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.

I strongly disagree.

> 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.

Exactly!  But only if the change is due the creation or deletion of
a namespaces.  Note the creation of both a namespace and a ANA group at
the same time.  In fact I don't see anything in NVMe which would allow
for this compound operations.  You always need to create an ANA group
first, and can then create a namespace using it, and you need to send the
Asymmetric Namespace Access Change AEN that a new ANA group has been
created, and then a Namespace Attribute Changed one.


> 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).

Yes, and the exclusion as it exists in the spec makes perfect sense -
the host does not need two AEN to notify that a namespace has been created
and as part of the creation was added to an AEN group.  But the host does
need an AEN when a new group has been created, period.  There also is no
language that allows skipping that.