[ofa-general] Re: [PATCH] core/mthca: Distinguish multiple IB cards in /proc/interrupts

Roland Dreier rdreier at cisco.com
Tue May 19 21:04:39 PDT 2009


[please hit "enter" every 70-80 characters or so, it makes email easier
to read and quote]

 > The current implementation of IB core module doesn't maintain a list
 > of allocated IB devices. Are you suggesting that we create a separate
 > list of allocated but not registered devices in addition to the
 > existing list of registered devices. Please clarify.

 > Alternatively, we can use the existing registered devices list named
 > 'device_list' in the IB core module to keep track of both allocated
 > and registered devices. Currently, the ib_device can be in one of
 > three states(IB_DEV_UNINITIALIZED, IB_DEV_REGISTERED,
 > IB_DEV_UNREGISTERED). We can enhance this to include 'INITIALIZED'
 > state and add the ib_device to 'device_list' with this new state at
 > ib_alloc_device_set_name() time. In this case, there will be no
 > changes to alloc_name() as it is already checking for device name
 > collision in a single list irrespective of the state of the device.

The second solution (adding an INITIALIZED state) seems simpler.  In
fact we could get rid of the UNINITIALIZED state after the patch series
since there wouldn't be a way to allocate an unitialized structure.

 > I wanted to point out that the proposed patch will not fix the
 > /proc/interrupts reporting issue for ConnectX IB devices because
 > request_irq() is done by mlx4_core and not by mlx4_ib. Also,
 > mlx4_core doesn't plug into IB core module.

Good point.  So I guess we should try to come up with a more general way
that works for mlx4 as well.  Perhaps enhance the PCI core so that all
MSI-X vectors for a device are reported in the /sys hierarchy (analogous
to the existing irq file that is under /sys/devices), which would work
for all possible devices, rather than having an RDMA-specific method?

 > I assume that there will be a transition period to allow deprecation
 > of ib_alloc_device_set_name() before we can apply this patch. Is my
 > assumption correct?

No, once all the drivers in the kernel are converted to the new API,
there's no longer any point in keeping the old API (especially given how
rare new RDMA drivers are).

 - R.



More information about the general mailing list