[ofw] Which API to use for IB project
Smith, Stan
stan.smith at intel.com
Thu Aug 6 08:32:30 PDT 2009
Take a look at ulp\dapl2\test\dtest\dtest.c for an example of DAPL coding.
Stan.
Thomas Peiselt wrote:
> Hi again,
>
> after playing around with libibverbs for a day and a half, I'm going
> to give uDAPL a try. The dapl specification is far superior to any
> documentation I found for libibverbs or winverbs, and all else being
> equal the portability and implementation effort determine the winner
> :-).
>
> thanks again to everyone contributing
>
> Thomas
>
> On Wed, Aug 5, 2009 at 6:14 PM, Sean Hefty<sean.hefty at intel.com>
> wrote:
>>> 1. latency
>>> 2. cpu load
>>> 3. low porting effort to linux compute nodes
>>> 4. implementation effort
>>>
>>> Latency is crucial, porting / implementation effort is just nice to
>>> have.
>>
>> For latency, really any of the RDMA APIs (winverbs, IBAL, ND,
>> libibverbs/librdmacm, uDAPL) will work well. The data path
>> operations for any of these calls is relatively thin.
>>
>> For CPU load, IBAL, libibverbs/librdmacm, and uDAPL allocate
>> additional system threads. Again, the overhead is small in each
>> case, but depending on how the interface is used, you may see
>> additional latency, in particular with event processing, like CQ
>> notifications.
>>
>> For portability, uDAPL and libibverbs/librdmacm are available on
>> both Windows and Linux. uDAPL abstracts everything, whereas
>> libibverbs does expose some OS specific structures, like fd's on
>> Linux. If you keep to the libibverbs API, the code should be easily
>> portable. However, if you touch the OS specific structures, more
>> work would be required to port, but you can also optimize somewhat
>> for each OS. This is how uDAPL is coded.
>>
>> - Sean
>>
>>
> _______________________________________________
> ofw mailing list
> ofw at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
More information about the ofw
mailing list