<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Dec 5, 2013 at 3:04 PM, Jason Gunthorpe <span dir="ltr"><<a href="mailto:jgunthorpe@obsidianresearch.com" target="_blank">jgunthorpe@obsidianresearch.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br></div><div class="im">
> We could provide a skeleton header that shows some examples on how<br>
> to implement a basic inline function for most critical calls and<br>
> then let them crib from there.<br>
<br>
</div>So, if we want to make this a goal I think it should be automatic, eg<br>
you implement your provider code according to a certain pattern, run<br>
script XYZ and you get the provider bypass header file.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br></div>
The normal libfabric path (fabric.h implicit include):<br>
<br>
 #ifdef LIBFABRIC_USE_MLX4_PROVIDER<br>
 #include <fabric-mlx4-provider.h><br>
 #else<br>
 static inline int indirect_func(OBJ *obj....) {return obj->function_table[..](obj,...);}<br>
 #endif<br>
<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I would like to see libfabric just include the providers in source and<br>
probably in binary. The provider library and ABI is just another<br>
hassle to deal with that has ended up serving no purpose.<br>
<br>
Especially since the providers are so small..<br><span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>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.</div>
</div><br></div></div>