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

[Christoph Lameter]

On Thu, Dec 5, 2013 at 3:04 PM, Jason Gunthorpe <
jgunthorpe at obsidianresearch.com> wrote:

>
> > We could provide a skeleton header that shows some examples on how
> > to implement a basic inline function for most critical calls and
> > then let them crib from there.
>
> So, if we want to make this a goal I think it should be automatic, eg
> you implement your provider code according to a certain pattern, run
> script XYZ and you get the provider bypass header file.
>

Too many ugly experiences with those. Skeleton files is something I have
found easy and usable with any editor of your picking. No troubles with
keeping a program functioning. A skeleton file can be used as a reference
and kept up to date. If a developer wants to look something up he can do
that with the skeleton headers/sources. Or do a reference driver.


> The normal libfabric path (fabric.h implicit include):
>
>  #ifdef LIBFABRIC_USE_MLX4_PROVIDER
>  #include <fabric-mlx4-provider.h>
>  #else
>  static inline int indirect_func(OBJ *obj....) {return
> obj->function_table[..](obj,...);}
>  #endif
>
>
Maybe only provide one function and avoid the #ifdefs? The optional
abstraction layer can use that function and then its expanded if it was
inlined. I would like this to be as trivial as possible.


> I would like to see libfabric just include the providers in source and
> probably in binary. The provider library and ABI is just another
> hassle to deal with that has ended up serving no purpose.
>
> Especially since the providers are so small..
>
>
What I would like to see is first of all low latency and low level access
to the hardware from user space preferably in a device independent way.
Functionality may be also useful from the higher levels but then those will
mostly be dealing with administrative tasks like setting up connections and
configuring the hardware. I think that is going to be a key for the future
because many forms of hardware aside from fabric controllers need high
performance access from user space. This is true f.e. for storage, ssds,
various other I/O devices and regular ethernet cards as well. If you are at
10G or higher then the kernel APIs become a problem due to their high
overhead.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofiwg/attachments/20131206/855e2481/attachment.html>