NVMe over Fabrics host: behavior on presence of ANA Group in "change" state

[Knight, Frederick]

>  > Can you please stop top-posting, its difficult to follow this  > 
> copy-pasting-top-posting chain that you are generating..
>
> My bad, I just had a hard time taming my mail client in all this 
> plain-text mode requirements.
> Also, I was a bit confused on how to handle branching-off replies :)
>
>
> In short, my opinion, after consulting with NVMe base specification 
> 2.0b stating is that:
>
> a) (8.1.2, page 340) "Namespaces that are members of the same ANA 
> Group perform identical asymmetric namespace accessstate transitions.
> The ANA Group maintains the same asymmetric namespace access state for 
> allnamespaces that are members of thatANA Group [...]The method for 
> assigning namespacesto ANA Groups is outside the scope 
> ofthisspecification."
> b) (8.1.2, page 340) "An ANA Group may contain zero or more 
> namespaces[...]The mapping of namespaces,[...] to ANA Groups is vendor 
> specific."
> c) (Figure 280, page 270) "ANAGRPID[...] If the value in this field 
> changes and Asymmetric Namespace Access ChangeNotices are supported 
> and enabled, then the controller shall issue an AsymmetricNamespace 
> Access Change Notice."
> d) (8.1.3.5, page 343) "While ANA Change state is reported by a 
> controller for the namespace, the host should:[...part about ANATT...]"
>
> Thus I see it that ANATT-based timer should be started only upon 
> condition that a namespace belongs to a group in this state but change 
> of relation between a namespace and it's ANA state can occur either 
> because ANA Group state has changes(and this would affect all of the 
> group members) or when ANAGRPID is changed(and this, if the new 
> group's ANA state differs from the old one, affects only one namespace 
> at a time).
>  From that, I find it is logical to no-op on the empty ANA Groups in 
> "change" state since I don't see the standard explicitly disallowing 
> that behavior in any way whatsoever.

Sorry, at least I and the original implementer (Christoph) disagree with your interpretation. Not to say that we are both wrong.

Adding Fred for some more clarity here.

[FK> ] I think I'm missing a bunch of context here. What is the original question?  I take a stab at some assumptions:
What is an empty ANA group?  That is an ANA Group with NO NSIDs associated with that group. Meaning the "Number of NSID Values" field is cleared to '0h' in the ANA Group Descriptor. That descriptor can be used to update some host internal state information related to that ANA group, but it has no impact on any I/O because there can be no I/O (since there are no NSID values).  So I'm not sure where that is going (because RGO=1 also can return ANA Groups that have state, but no attached namespaces (it's a way to get group state without any NSID inventory requirements)).

> ... or when ANAGRPID is changed(and this, if the new 
> group's ANA state differs from the old one, affects only one namespace 
> at a time).

Now this treads into the TP 4108 space.  There is currently no way to report anything that impacts "only one namespace at a time".  ANY report of a change (AEN) for any namespace is always reporting a state change for the entire group that contains the namespace where the event occurred.  That is the WHOLE POINT of ANA Groups.  AND, that is the whole point of TP4108 - to address that kind of situation (where a change impacts only 1 namespace). Until TP4108 address this situation, a single namespace changing the ANAGRPID is ugly.  Maybe we should get to work on that TP.

Also remember that "Change" state does NOT have to be visible to the host; the controller can transition through the Change state before the host ever notices - so, to the host, it can look like all the namespace in the Group transition directly from optimized to non-optimized (as one example).

Not sure if that helps any. What was the original question?

	Fred