On Tue, Dec 18, 2018 at 01:37:15PM -0500, Dennis Dalessandro wrote: > 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. First, other drivers and mlx4 among them don't have such issues with debugfs at all. They rely on PCI-ID. Whatever, I'm done with hfi1 thing. It is your problem now, not mine. Please drop this patch. > > -Denny
Attachment:
signature.asc
Description: PGP signature
