On Wed, Mar 06, 2019 at 06:20:18PM +0100, Nicolas Morey-Chaisemartin wrote:
>
>
> On 3/6/19 6:13 PM, Leon Romanovsky wrote:
> > On Wed, Mar 06, 2019 at 05:11:59PM +0100, Nicolas Morey-Chaisemartin wrote:
> >>
> >> On 3/6/19 11:08 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 naming policy is possible to chose from NAME_KERNEL, NAME_PCI,
> >>> NAME_GUID or NAME_FALLBACK, which is controlled by udev rule.
> >>>
> >>> * 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: "mlxp0s12f4".
> >>> * NAME_GUID - read system image GUID information in simillar manner to
> >>> net MAC naming policy. Example "mlxx525400c0fe123455".
> >>> * 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 a matter of precaution, we set default naming policy to be
> >>> NAME_KERNEL, but will change it later to NAME_FALLBACK.
> >>>
> >> You probably should extend udev.md to document this value (with pretty much a copy of your commit message).
> > I will do, just wanted to be sure that we are agree on the implementation.
>
> >
> >> Also, not sure coding this value directly into the udev script is the right thing to do.
> >> At least RPM may mess with you file during an update if you change it.
> >> We already have a /etc/rdma with a bunch of stuff. Could we stick in there too ?
> > I did it to be similar to other /usr/lib/udev/rules.d/60-persistent-*.rules files.
> > Users who are needed to overwrite it, are expected to use systemd and
> > create their local rule in /etc/udev/rules.d/.
> You're right. In that case, patch #5 needs to use %config(noreplace) %{_sysconfdir}/udev/rules.d/ (same as ipoib persistent) so RPM won't mess it up.
Thanks, I'll change.
>
> >> It would also be nice if we could rename the associated IPoIB device as well.
> > I was under impression that it is netdev job to give right names for IPoIB devices.
>
> Not sure who is suppose to do it. But it would be nice for both to be "matching".
ok, I'll take a look on it after we will converge with real devices :)
>
> >
> >> We do have the persistent-ipoib udev rule but it'd probably if they had a name "matching" the IB device by default so in most use case people
> >> do not have to set these rules manually and never have to look which netdev matches which IB device.
> >> If we go with my #2 point, we could add a setting to enable/disable this feature. And make sure that the persistent rule is triggered afterwards so legacy name are not overwritten.
> > It won't be overwritten if I rename 99-persistent-rdma ... to be 70-persistent-rdma ...
>
> Couldn't there be an issue if the rule is triggered before the rdma-hw-modules.rules ?
> I'm guessing the persistent-ipoib one does not have this issue as it triggers when the ipoib is up (meaning HW and ULP have been loaded and the new device shows up)
I'm relying on "PROGRAM" directive of UDEV rules, this is called once
kernel node is created and it effectively ensures that rename is issued
only after driver was loaded.
Udev rules are actually read and every later in chain directive
overwrites previous one. After all directives are read, the rule is
executed. So the order 99-per... or 70-per.. simply means which rule
will be overwritten.
Thanks
>
> Nicolas
>
Attachment:
signature.asc
Description: PGP signature
