[PATCH rfc 6/6] nvme-fabrics: expose support for traddr as dns names to userspace

[Sagi Grimberg]

>> I listed that as an option, you should read it.
>> There are some disadvantages in doing that, it needs to co-exist
>> with the mandatory (today) traddr, which is now will be mandatory
>> only for fc. And also now the user will need to decide a conflicting
>> existing functionality in nvme-cli that today accept dns names as
>> a format to traddr, but now will need a different argument for
>> passing it to the kernel.
>>
>> Anyway, its possible, but more complicated IMO.
>>
>> Plus, I also think that it can be useful for the kernel to signal
>> capabilities and support for things that are not only valid tokens.
> 
> I cross-checked with nvme-cli; there we read the list of available 
> tokens upon failure to give the user a hint which arguments are 
> supported by any given kernel.
> So by that regard it should be fine to just add 'dns' as a parameter
> here.
> 
> Reviewed-by: Hannes Reinecke <hare at suse.de>

Thanks,

I'd also want to hear from others (Keith, Christoph, Chaitanya, Daniel,
Martin...)

Where do you stand on the kernel exposing capabilities that do not
manifest in "valid tokens" when writing to /dev/nvme-fabrics ?

today when we read /dev/nvme-fabrics we get a string with all
the valid tokens. that is useful for userspace to understand what
it can or cannot pass in a fabrics connection string.

In the example here, we are trying to introduce a new format for
traddr argument that is now supported by the fabrics driver (tcp/rdma)
where traddr can now be ipv4, ipv6 or a dns name (where before this
patchset it could only be ipv4 or ipv6).

The question is:
Do we enforce that every new capability must come with a matching valid
token? Or do we want to expose capabilities that are not necessarily
come with dedicated tokens (like in this example)?

I think the latter is a be better approach. But could be convinced
otherwise...