On Wed, May 13, 2020 at 08:25:41AM -0700, Bart Van Assche wrote: > On 2020-05-13 05:43, Jason Gunthorpe wrote: > > On Wed, May 13, 2020 at 03:38:37PM +0300, Kamal Heib wrote: > >>>> Correct me if I'm wrong, Do you mean check the return value from > >>>> rdma_cap_ib_mad()? > >>> > >>> I think so. > >>> > >>> Thanks > >> > >> Well, this function will not help in the case of VFs, because the flag > >> that is checked in rdma_cap_ib_mad() is RDMA_CORE_CAP_IB_MAD which is > >> set almost for each create IB device as part of RDMA_CORE_PORT_IBA_IB or > >> RDMA_CORE_PORT_IBA_ROCE or RDMA_CORE_PORT_IBA_ROCE_UDP_ENCAP. > > > > AFAIK this case only happens for mlx4 devices that use the GUID table > > to emulate virtual IB ports. In this case there is no bit to control. > > > > I didn't quite understand why srpt has this stuff, does it mean it is > > broken on mlx4 vports? Why allow the failure? > > The commit message of the code that introduced the most recent > IB_PORT_DEVICE_MGMT_SUP changes is as follows: > > commit 09f8a1486dcaf69753961a6df6cffdaafc5ccbcb > Author: Bart Van Assche <bvanassche@xxxxxxx> > Date: Mon Sep 30 16:17:01 2019 -0700 > > RDMA/srpt: Fix handling of SR-IOV and iWARP ports > > Management datagrams (MADs) are not supported by SR-IOV VFs nor by iWARP > ports. Support SR-IOV VFs and iWARP ports by only logging an error > message if MAD handler registration fails. > > In other words, on my setup the ib_srpt driver was working find with SR-IOV. But it won't be properly discoverable without the IB_PORT_DEVICE_MGMT_SUP flag being set on the physical port? Jason
