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

[Daniel Wagner]

On Thu, Aug 17, 2023 at 02:09:39PM +0300, Sagi Grimberg wrote:
> 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...

My gut feeling tells me in the long run it's good to have some generic
way to inform userspace of options format or feature changes. I am
pondering if sysfs wouldn't be the better place for this. But then we
would need to gather this info from two places. Not nice.

Just to through in another idea, we could also introduce a version
scheme, e.g.

...,traddr=%s at v2,...

If I got this right, the current libnvme token parser would just ignore
the versioning string.

Obviously, the simplest way is to introduce just a new token and be done
with it. I somewhat don't like it. Maybe I am trying to over engineer
this.