[ofw] Which API to use for IB project

[Tzachi Dar]

You can find the ibv_read_lat Under trunk\tests\perftest\read_lat.

As for the question about uDAPL: For a very long time uDAPL on windows
was orphan.
Personally I never had anything to do with it, and as far as I can tell
only Intel is using it (on windows).

Since I know nothing about it, I can not really recommend it (which of
course doesn't say it is good or not good).

Thanks
Tzachi

> -----Original Message-----
> From: Thomas Peiselt [mailto:dispanser at googlemail.com] 
> Sent: Monday, August 03, 2009 9:16 PM
> To: Tzachi Dar
> Cc: ofw at lists.openfabrics.org
> Subject: Re: [ofw] Which API to use for IB project
> 
> Hello,
> 
> thank you for your elaborate response.
> 
> On Mon, Aug 3, 2009 at 5:22 PM, Tzachi 
> Dar<tzachid at mellanox.co.il> wrote:
> > I guess that if you can live with latency of ~5us you 
> should be using SDP which will give you the minimum 
> development effort.
> 
> development is only a minor issue -- unless we're talking 
> developer-years here :-).
> 
> >
> > If you want to be in the area of ~1us latency you should be 
> using one of the following 3 options IBAL ND or winverbs. I 
> guess that once it comes to latency this are the best choices.
> 
> It appears that ND is MS-only and results in even more 
> vendor-lock in, which we would like to avoid. From the 
> remaining two, IBAL seems to be the more mature 
> implementation, whereas WV has a bright future. I personally 
> prefer the latter, all else being equal, especially when this 
> API is closer to its linux counterpart.
> 
> We're currently running XP x64, so 32bit support will not be an issue.
> 
> > Please note that to get the best latency one should be 
> using RDMA write and pool on the memory for completion (see 
> the ib_write_lat program for an example).
> 
> speaking of example code, is there anything in the trunk 
> demonstrating the usage of the winverbs api? The docs mention 
> ibv_read_lat and friends but I'm unable to find these, or 
> anything else using the winverbs header file.
> What about uDAPL? It claims to be a thin layer abstracting 
> RDMA-enabled communication from the underlying hardware and 
> the API is OS-independent. Additionally, the endpoint state 
> diagram from the specification is very close to what we 
> currently have in our tcp/ip overlapped I/O implementation. 
> Where's the drawback?
> 
> 
> Thanks again,
> 
> Thomas
>