Re: [PATCH] [RFC] IB/hfi1: Fix port ordering issue in a multiport device

[Doug Ledford <dledford@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2116 bytes --]

On Wed, 2017-01-18 at 14:08 -0700, Jason Gunthorpe wrote:
> On Wed, Jan 18, 2017 at 04:01:00PM -0500, Doug Ledford wrote:
> 
> > 
> > OK, sure, as far as the reordering stuff is concerned, all you need
> > to
> > do is to make use of the EPROBE_DEFER return option to your PCI
> > probe
> > routine.  That way, when you get the probe for the out of order
> > port,
> 
> EPROBE_DEFER is intended when waiting on other components the driver
> may need, not for setting stable names.

What it's intended for, and what it can be used for, need not be the
same.

> This is a 'stable device naming' problem, which we have never tried
> to
> solve in RDMA.

No, that would imply they must be hfi1_0 and hfi1_1, when this is not
the case.  If you had two cards in this system, both dual port, then
you may be wanting to rename hfi_3 to hfi1_2 and vice versa.  It is a
relative name problem, not a stable name problem.  We need only reverse
the order that the ports are probed in, their names are whatever they
end up being once reversed.

> udev is the expected kernel way to solve this. Trying to hack stable
> names by forcing device bind order is horrible.

This is a manufacturing defect.  Something I'm sure Intel wants to
resolve without requiring users to go in and manually name their ports.
 I have no doubt that they would prefer that the user remain blissfully
unaware of the issue, all except for the ones that probably reported it
and already have their system cabled up wrong as a result.

> hfi runs smack into this because it is the first scheme to actually
> typically operate in a multi-struct ib_device world, which means they
> get to solve it properly :\

No, mlx5 could have easily hit this too as their ports are separate PCI
functions.  As I said, it's a manufacturing defect and that means I'm
sure Intel would prefer to solve it silently and automatically.  I
would if I were them anyway.

-- 
Doug Ledford <dledford@redhat.com>
    GPG KeyID: B826A3330E572FDD
   
Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]