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:[email protected]] > Sent: Monday, August 03, 2009 9:16 PM > To: Tzachi Dar > Cc: [email protected] > 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<[email protected]> 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 > _______________________________________________ ofw mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
