On Tue, Sep 25, 2018 at 09:42:02AM -0500, Steve Wise wrote: > > > On 9/25/2018 9:28 AM, Jason Gunthorpe wrote: > > On Tue, Sep 25, 2018 at 08:52:48AM +0300, Leon Romanovsky wrote: > >>> I was thinking on this some more, and we don't really need to wait for > >>> netlink or to add uverbs stuff to netlink. > >>> > >>> We should add a new ioctl to return the 'driver description' from > >>> uverbs. > >>> > >>> This changes the rdma-core flow a bit as it cannot bind the driver > >>> until after opening the uverbs FD, but it sure makes more sense .. > >> > >> It may be helpful for rdma-core, but for Steve's work it won't. He is > >> not supposed to touch uverbs file just to understand on which software > >> RDMA device to operate. It means that knowledge of driver_id will be > >> exposed over netlink anyway, and I think that it won't be cleanest thing > >> to duplicate interfaces. > > > > Steve's problem is entirely inside rdma-core though.. > > > > Jason > > > > Correct. I have a series that uses a new netlink messages to create rxe > links, and name them. It works fine. (I'll post this as an RFC soon. > But I should rebase it on Jason's device name series). Post as RFC. > > The remaining unresolved issue is that the rdma core associates uverb > devices with the rxe provider by requiring the rxe device name to begin > with "rxe". > > Steve. > > > Steve. >
Attachment:
signature.asc
Description: PGP signature
