[Openframeworkwg] Some concerns about the new Fabric/IBverbs API

Christoph Lameter christoph at graphe.net
Wed Dec 4 20:11:57 PST 2013


On Dec 4, 2013, at 10:05 PM, Jason Gunthorpe <jgunthorpe at obsidianresearch.com> wrote:

> 
>> Isnt the loader used to load an provider implementation that can then be used
>> by ibverbs? Can these not be simple functions provided by an provider provided
>> library instead of a vector of functions? dlopen and friends can manage that.
> 
> Yah, you can use dlopen to get the provider function pointers, but it
> doesn't fundamentally help anything.

Well we are doing the same in the existing proposal with arrays of functions. The inline argument is something that I have no idea how to deal with in the dlopen case.


>> VFIO could be used as a base API for getting access to the device. Then we may
>> need to have some additional syscalls that may be required to provide
>> functionality that the existing VFIO interface does not provide.
> 
> I think the kernel API issue is orthogonal - there is nothing in the
> 'libibverbs' API that is strongly tied to the kernel?

Well management of resources of the NIC that is system or card specific needs to be either in the kernel or in a special user space process. So I think at least a minimal part needs to be in the kernel. Maybe the VFIO management features are sufficient though.

> Someone could write a VFIO provider for verbs, for instance.

Yes and that would also make the VFIO provider code only dependent on the hardware infrastructure and no longer kernel version dependent.
No need to build kernel modules and deal with all the pain that comes with handling those.






More information about the ofiwg mailing list