On Fri, Jan 04, 2019 at 12:53:03AM +0000, Hefty, Sean wrote: > > > It is probably a bad idea to implement the uverbs abi without copying > > > the new machinery for doing so from verbs, it is complicted, and the > > > ioctl support makes it even more tricky. > > > > I second the idea that trying to do the uverbs kernel API outside > > libibverbs is a bad idea. My preference would be to have a new > > libibverbs provider that supports what efa needs and then have libfabric > > use that, simply because of the issue you mention here. > > I would agree if we can figure out a way to avoid the libibverbs API > overhead for fast path operations. This has been available for years now, the 'dv' interface does exactly this sort of bypass. The Mellanox drivers in ucx, dpdk, vma, etc all use the dv path for datapath operations. I think that is a consensus that EFA should build its libfabric provider on libibverbs & 'efadv'.. Jason
