On 12/18/2018 12:57 PM, Leon Romanovsky wrote:
On Tue, Dec 18, 2018 at 02:17:15PM +0000, Ruhl, Michael J wrote:
-----Original Message-----
From: Leon Romanovsky [mailto:leon@xxxxxxxxxx]
Sent: Tuesday, December 18, 2018 9:00 AM
To: Ruhl, Michael J <michael.j.ruhl@xxxxxxxxx>
Cc: Jason Gunthorpe <jgg@xxxxxxxxxxxx>; Dalessandro, Dennis
<dennis.dalessandro@xxxxxxxxx>; Yuval Shaia <yuval.shaia@xxxxxxxxxx>;
Doug Ledford <dledford@xxxxxxxxxx>; Marciniszyn, Mike
<mike.marciniszyn@xxxxxxxxx>; RDMA mailing list <linux-
rdma@xxxxxxxxxxxxxxx>
Subject: Re: [PATCH rdma-next] RDMA/hfi1: Use PCI-ID as an identification in
debugfs
So we get:
/sys/kernel/debug/hfi/hfi1_<port>
For each HFI we will increment port, so for two instance of the driver, there
will
always be a uniquely defined name.
From that perspective, as far as I can tell, the HFI driver is meeting the
"globally uniqueness" requirement.
We do register with the IB driver using the hfi1_class_name/port, but that is
a
stored separately, and is completely unrelated to our debugfs usage.
If the IB name is renamed, there is no effect on the HFI debugfs files.
The data structure and function name are perhaps poorly named, but as far
as I can tell are unique, and not in conflict with anything from the IB space.
ok, as you wish, let's disable device rename for hfi1. We can't allow
ambiguity for the users.
Leon,
Maybe you need to define "device rename".
My understanding is that we are talking about the rdma tool function:
rdma dev rename
Which is matched with the core function:
ib_device_rename()
Is that what you are referring to? Or are you renaming something else?
When I'm talking about device rename, I see user space ability from
RDMA netlink interface to rename any IB device to any other name,
rdmatool is one of the available interfaces, while ib_device_rename() is kernel
complimentary part.
I do not see any relationship to the HFI debugfs directory, or how this is
relates to this function in any way.
Saying that it is "wrong" and that other drivers do it "differently" is not
explaining why this is not correctly unique, why this will not work if someone
does an ib_device_rename(), or how this is ambiguous.
What is the ambiguity?
How is this causing ambiguity for users?
How does this affect ib_device_rename()?
Why does this naming convention disrupt the ability of the ib_device_rename()
function to work?
My ultimate goal is to combine that RDMA netlink functionality with
systemd boot-up scripts. Those scripts are supposed to create unique
device names without any relation to the probe order and/or error
reset flows.
Being part of the boot process, users will see devices in similar to
netdevices, e.g. rdma0p3 or xGUID or anything else (less important for now)
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
From user perspective, administrator will issue "rdma dev"/ibv_devinfo and
will see list of already renamed devices. After that the simple lookup in
corresponding debugfs entry will show that all devices with correlated names
except hfi* are shown there. For hfi1, he will have hard time to translate
new name visible in various tools to old name presented in debugfs.
This is ambiguity, from my point of view.
Yes, but it doesn't matter that much. What is in debugfs doesn't
absolutely have to match the name in rdmatool/dmesg/etc.
Debugfs is for debug use, so whatever makes driver debugging easier is
the way to go. In our case with the tools we have in place it is maybe
better to not break things.
As Doug mentioned the hfi1 driver doesn't suffer the same shortcoming of
other drivers due to the naming scheme used. So the only reason to
change to pci-id is cosmetic. There is no technical problem here.
-Denny
