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

[Alex Talker]

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

Now, moving to the rest...

 > If your use-case needs more than 128 groups, you can send a patch.

I thought these constants were defined by optimization or something but 
I ain't no expert on the code base :)
In that case, what is your opinion on adding number of groups & 
namespaces as module parameters(to nvmet) alike "mulipath"(i.e. to be 
only set upon the load)?
As I saw in earlier discussion here on different matter, in production 
there's systems which provide huge number of namespace(and possibly 
groups too)
and this extra parameters would allow for easy mock-up of such setups to 
look for bottleneck and the like, without re-patching the code for each try.
Would appreciate your advice on possible disadvantages of such an approach!

 > nvmet is actually violating the spec right now because it doesn't
 > set bit 6 in ctrl identify anacap, and it clearly exposes anagrpid as
 > a config knob, so either we need to block it, or set that bit.

So, my "expertise" is lacking on this one but if I get what you saying 
correctly,
it means that for past hell knows how much time I could change the ANA 
group on target, AEN(I think? the notification functionality I mean) 
would be successfully sent
and hosts were quite okay with what's going on but somebody forgot to 
advertise such capability in the controller's info?
I literally used my workaround on these pre-"native multipath" host 
times(I'm looking on CentOS 7 for example) and it seem to went okay, so 
I'd vote for the bit.
So...this is like +1-2 patch(-es)?

 > No attachments please, follow the instructions in:
 > Documentation/process/submitting-patches.rst

Gotcha, already working on it.
I tested the straightforward patch on the latest release and it seems to 
be working as expected
(i.e. ANATT triggers only on on non-empty "change" state groups), so I'm 
on the stage of trying out the 'git send-email' :)

Thanks for your time anyway!

Best regards,
Alex