Re: [PATCH 18/18] nvmet-tcp: add configfs attribute 'param_keyring'

Hannes Reinecke
2023-04-17T14:02:05Z

On 4/17/23 15:50, Sagi Grimberg wrote:
>
>>>>>> Add a configfs attribute to list and change the default keyring.
>>>>>
>>>>> is the keyring an attribute of a port? or a subsystem? Why the choice
>>>>> of making it per port?
>>>>>
>>>> As per discussion at fmds each port might want to use different
>>>> credentials.
>>>> We can move it to subsystems if we decide we don't want to support
>>>> that use-case.
>>>
>>> I think we should move it to the subsystem in Linux.
>>>
>> Easier said than done.
>>
>> We can only fetch the subsystem once we have the NQN, which we will
>> know after the connect command.
>> But out of necessity the connect command will only be transferred
>> after TLS handshake completed, so there is not subsystem NQN allowing
>> us to figure out the correct subsystem.
>>
>> So we'll have to keep it at the port level, I'm afraid.
>
> Question, why does nvmet needs to support user defined keyrings?
> I understood your argument for the host, but why should the target
> support it?

Hmm. Originally I implemented it to be similar to the host
configuration, but from the implementation we don't _actually_ need it
as we select the key from the entire key store.
Having it is just a nice way of avoiding having to have a daemon
configuration.
So if you insist we can drop it for the initial implementation.

Cheers,

Hannes