> > >>>> Why? This is not current practice for rdma devices: the core names
> them.
> > >>>
> > >>> That is a bad practice.. Leon has been working on device renaming
like
> > >>> netdev has, so it would make no sense to have no name here and have
> > >>> renaming down the road.
> > >>>
> > >>> Jason
> > >>>
> > >>
> > >> This causes a slit kink in arbitrarily naming rxe rdma devices. From
> > >> providers/rxe/rxe.c:
> > >>
> > >> static const struct verbs_match_ent hca_table[] = {
> > >> /* FIXME: rxe needs a more reliable way to detect the rxe
device */
> > >> VERBS_NAME_MATCH("rxe", NULL),
> > >> {},
> > >> };
> > >>
> > >>
> > >> So when I add a new rxe device named "foo0", it gets added fine in
the
> > >> kernel, but the user space side skips it. It doesn't show up in
> > >> ibv_devices or ibv_devinfo for example. But the sysfs entries are
> there...
> > >
> > > Yes, this needs fixing too :(
> > >
> > > I was hoping we'd get to netlink discovery before this became an
> > > issue.. The right solution is to use the new driver id number, I
> > > think.
> > >
> > > Jason
> > >
> >
> > Do you mean the rdma_driver_id enum? That would I methinks...
>
> Neltink ibdev index + rdma_driver_id will give us perfect match of
> underlying device.
>
> Thanks
So currently there is this verbs_match_ent struct and VERBS_MATCH* macros in
libibverbs/driver.h. These allow providers to specify either a PCI
vendor/device ID or a string that the libibverbs core uses to match
providers to devices. The string is a hack to support thinks like RXE that
don't have a specific vendor/device ID since it supports any arbitrary NIC
device.
Should verbs_match_ent and friends be enhanced, for example, to add match by
driver_id? And currently the kernel side does nothing with driver_id.
Should it export the driver id to sysfs?
Leon, do you have some work in progress that I should be leveraging for this
link add project?
Thanks,
Steve.
