Re: [PATCH] kernel-boot: Do not perform device rename on OPA devices

[Leon Romanovsky <leon@kernel.org>]

On Wed, Feb 05, 2020 at 03:12:27PM -0400, Jason Gunthorpe wrote:
> On Tue, Feb 04, 2020 at 08:55:20AM -0500, Goldman, Adam wrote:
> > From: "Goldman, Adam" <adam.goldman@intel.com>
> >
> > PSM2 will not run with recent rdma-core releases. Several tools and
> > libraries like PSM2, require the hfi1 name to be present.
> >
> > Recent rdma-core releases added a new feature to rename kernel devices,
> > but the default configuration will not work with hfi1 fabrics.
> >
> > Related opa-psm2 github issue:
> >   https://github.com/intel/opa-psm2/issues/43
> >
> > Fixes: 5b4099d47be3 ("kernel-boot: Perform device rename to make stable names")
> > Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
> > Signed-off-by: Goldman, Adam <adam.goldman@intel.com>
> >  kernel-boot/rdma-persistent-naming.rules | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/kernel-boot/rdma-persistent-naming.rules b/kernel-boot/rdma-persistent-naming.rules
> > index 9b61e16..95d6851 100644
> > +++ b/kernel-boot/rdma-persistent-naming.rules
> > @@ -25,4 +25,4 @@
> >  #   Device type = RoCE
> >  #   mlx5_0 -> rocex525400c0fe123455
> >  #
> > -ACTION=="add", SUBSYSTEM=="infiniband", PROGRAM="rdma_rename %k NAME_FALLBACK"
> > +ACTION=="add", SUBSYSTEM=="infiniband", KERNEL!="hfi1*", PROGRAM="rdma_rename %k NAME_FALLBACK"
>
> We are moving to the new names by default slowly, when wrong
> assumptions are found in other packages they need to be updated and
> their fixes pushed out.
>
> At some point the major distros will default this to On. People using
> leading edge distros can turn it off with the global switch Leon
> mentioned.
>
> This is the same process netdev went through when they introduced
> persistent names.
>
> If I recall, hfi was one of the reason this work was done. HFI has
> problems generating consistent names for its multi-function devices in
> various cases and I NAK'd the kernel hack to try and 'fix' that.

You remember correctly, it was related to the bug in production where
physical ports were not aligned with their physical location and the
module parameter was supposed to "reverse" the enumeration order.

Something like that.

Thanks

>
> Jason