On 7/23/21 10:02 PM, Vladislav Bolkhovitin wrote:

Another comment is that better to perform CRC check of dhchap_secret and
generation of dhchap_key right where the secret was specified (e.g.,
nvmet_auth_set_host_key() on the target side).

No need to do it every time for every connection and by that increase
authentication latency. As I wrote in the other comment, it might be 128
or more connections established during connecting to a single NVMe-oF
device.

And this is something I did deliberately.
The primary issue here is that the user might want/need to change the 
PSK for re-authentication. But for that he might need to check what the 
original/current PSK is, so I think we need to keep the original PSK as 
passed in from the user.
And I found it a waste of space to store the decoded secret in addition 
to the original one, seeing that it can be derived from the original one.
But your argument about the many connections required for a single NVMe 
association is certainly true, to it would make sense to keep the decode 
one around, too, just to speed up computation.
Will be updating the patchset.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.de                              +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer