On 03/10/2019 11:19 AM, Leon Romanovsky wrote: > From: Leon Romanovsky <leonro@xxxxxxxxxxxx> > > Generalize the naming scheme for RDMA devices, so users will always > see names based on topology/GUID information. Such naming scheme has > big advantage that the names are fully automatic, fully predictable > and they stay fixed even if hardware is added or removed (i.e. no > reenumeration takes place) and that broken hardware can be replaced > seamlessly. > > The name is combination of link type (Infiniband, RoCE, iWARP or OPA) > and the chosen naming policy, like NAME_KERNEL, NAME_PCI, NAME_GUID > or NAME_FALLBACK. Those naming policies are controlled by udev rule > and can be overwritten by users. > > * NAME_KERNEL - don't change names and rely on kernel assignment. This > will keep RDMA names as before. Example: "mlx5_0". > * NAME_PCI - read PCI location and topology as a source for stable names, > which won't change in any software event (reset, PCI probe e.t.c.). > Example: "ibp0s12f4". > * NAME_GUID - read system image GUID information in simillar manner to > net MAC naming policy. Example "rocex525400c0fe123455". > * NAME_FALLBACK - automatic fallback: NAME_PCI->NAME_GUID->NAME_KERNEL > > No doubts that new names are harder to read than the "mlx5_0" everybody, > is used to, but being consistent in scripts is much more important. > > As part of this change we add special function to generate and install > in proper place UDEV binaries. Those files are expected to be in one > level above already declared general rules.d location, in default case > it will be or in /usr/lib/udev or in /lib/udev for old distributions. > > Such location is not needed to be configured by users because they > already provide -DCMAKE_INSTALL_UDEV_RULESDIR if they want. Does this naming policy play nice with systemd's latest naming[1] policies? Currently systemd will assign 'ib*' to an RDMA device, but it is not clear to me that your current rules file sets enough variables to prevent systemd from renaming RDMA devices. [1] https://github.com/systemd/systemd/blob/master/man/systemd.link.xml#L241 -Jon
