On Mon, Jul 31, 2017 at 10:47:05AM -0600, Jason Gunthorpe wrote:
> On Mon, Jul 31, 2017 at 03:00:47PM +0000, Bart Van Assche wrote:
> > On Mon, 2017-07-31 at 14:36 +0300, Leon Romanovsky wrote:
> > > I would like to propose the discussion about ability to add
> > > persistent device naming to RDMA subsystem.
> > >
> > > Right now, the devices receive their names by simple addition of new free
> > > index to the name (mlx5_0, mlx5_1 ...). Such naming scheme depends on the
> > > PCI probing and in case of device reset can rename device.
> > >
> > > Such situation doesn't help to provide constant udev rules, reliable
> > > ibverbs hotplug and advanced "set command" of RDMAtool which at some
> > > point of time will require reinit of ib_device.
> > >
> > > In this discussion, I want to present netdev implementation of such
> > > feature, talk about implications on libibverbs and suggest possible
> > > device name convention.
> >
> > Hello Leon,
> >
> > Does this mean that there is user space software that depends on these names?
> > Shouldn't all user space software be independent of the device names assigned
> > by the kernel? For e.g. SCSI disks this was solved a long time ago by making
> > /dev/disk/by-id/${name derived from persistent ID} soft links available. An
> > example:
> >
> > $ ls -l /dev/disk/by-id/scsi-35001b44c698c2947
> > lrwxrwxrwx 1 root root 9 Jul 31 07:53 /dev/disk/by-id/scsi-35001b44c698c2947 -> ../../sda
>
> The problem with RDMA is it relies heavily on sysfs, and the sysfs
> path name is what is being proposed to be changable.
>
> The best fix is going to be to consistently use the new stable index
> to access all information, which means effectively obsoleting sysfs.
>
I want to take RDMA one step more,
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
I called the topic name "persistent", but the right name is "predictable".
Thanks
> Jason
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Attachment:
signature.asc
Description: PGP signature
