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

[Sagi Grimberg]

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