On 11/19/2018 12:10 AM, Leon Romanovsky wrote:
On Sun, Nov 18, 2018 at 10:56:15PM -0500, Dennis Dalessandro wrote:
On 11/18/2018 9:29 AM, Leon Romanovsky wrote:
Hi,
I want to clarify why IB device rename functionality didn't change
debugfs and would like to ask what to do next.
In drivers/infiniband/hw/*, we have 6 devices which are calling
to debugfs_create_dir() in order to create debugfs root.
The output is located in /sys/kernel/debug/.
Such folders are created during driver module load and some of the drivers
creates subfolders for every device initialized, during device probe.
1. PCI-based connection
MLX5 and cxgb4 drivers separate the different device by their PCIs.
[leonro@server ~]$ sudo ls /sys/kernel/debug/mlx5/
0000:00:0c.0
2. Based on IB device name
HFI1, ocrdma and qib create subfolders with device index embedded in it,
like hfi1_0,...,hfi1_N
3. No-separation between devices
USNIC like this.
So device rename works seamlessly for type #1 and #3. Wile for type #2,
the debugfs entries don't change.
Right now, I see three options:
1. Do nothing.
2. Convert type #2 drivers to be type #1.
3. Add callback/extra implementation in IB/core to support one live
driver (hfi1) and two frozen ones.
It's certainly not accurate to call qib frozen. We may not plan on any
new features but we do intend to keep it live and provide fixes should
the need arise.
It is semantic, the idea is the same: no new feature are planned for it.
There is a very big difference. qib is still in a keep it working state
as opposed to ipath when we deprecated it's use which was in a keep it
compiling state.
I think the type #2 is much more user friendly than putting in the PCI-ID
so why not convert type #1 to be type #2?
As Parav explained, type #1 is coming from netdev side and from my
small research, debugfs entries based on PCI are standard in netdev,
including Intel drivers (i40e).
See my reply to Parav.
So no, we can't rename whole netdev just for three IB drivers.
It doesn't matter how many of what driver does what. I'm concerned with
what is the correct approach.
Now that being said I would imagine we could go with either approach and
leave it up to the administrator to create a udev rule or something and
make symlinks to keep existing tools compatible. So I don't think we need
to support both. The question is which is better #1 or #2?
Administrators don't care about debugfs entries and more on that any
sane administrator will disable debugfs on production system. It is
unlikely that such udevs are needed for them.
Point is, without a good reason we can't break what already works.
Saying administrators that rely on debugfs are not "sane" is not sufficient.
So if there is a way to employ a work around for admins to keep existing
tools working that makes such a change a much easier pill to swallow.
-Denny
