On 04-Jan-19 05:39, Jason Gunthorpe wrote: > 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'.. As long as this won't hurt EFA's performance, sounds good to me. We will do that.
