> > 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. I don't believe this would be noticeable for EFA, specifically, but it shows up on other NICs. - Sean
