<html>
<body>
<font size=3>At 06:39 AM 7/13/2005, James Lentini wrote:<br><br>
<br>
<blockquote type=cite class=cite cite="">On Tue, 12 Jul 2005, xg wang
wrote:<br><br>
<blockquote type=cite class=cite cite=""> Frankly
speaking, I can not distinguish the function of SDP and DAPL. Since
Lustre is a file system, it runs on kernel. So I think maybe kDAPL is
better.</blockquote><br>
SDP stands for the Sockets Direct Protocol. The protocol is designed to
support the Berkley Sockets API. This allows code already using the
Sockets API to easily use InfiniBand by simply changing the socket
type.</font></blockquote><br>
One clarification: SDP supports both synchronous and asynchronous
sockets. The OpenGroup ICSC released the sockets extensions API a
number of months back that enables the full performance provided by SDP
to be tapped. The SDP specifications can be found at the IBTA for
IB and at the RDMAC for RNIC web sites.<br><br>
<br>
<blockquote type=cite class=cite cite=""><font size=3>kDAPL is the kernel
Direct Access Provider Library. It is an API that supports RDMA networks
(InfiniBand, iWARP, etc.).<br><br>
<blockquote type=cite class=cite cite=""> But for ULP
application, what is the advantage and disadvantage of SDP and DAP
? While you implementation an application, will you use SDP or
DAPL, and why? I just wonder the difference between them from the
application view.</blockquote><br>
First off, SDP is a protocol and kDAPL is an API. Since SDP is a
protocol, you will only be able to communicate with other nodes that
implement SDP.<br><br>
Another thing to consider is the differences in the APIs. SDP accessed
with traditional Sockets API. This makes porting applications to it easy,
but doesn't give you much fine grained control over how the RDMA network
is used. </font></blockquote><br>
Sockets by definition is interconnect and topology independent.
Network controls are managed separately. The best that an
application should do is signal its requirements, e.g. using diffserv or
similar standard.<br><br>
<blockquote type=cite class=cite cite=""><font size=3>kDAPL was designed
specifically for RDMA networks with lots of features that allow you to
control how the network is used. This is good if you are writing new
code, but means that old code needs substantial
porting.</blockquote><br>
Ideally, applications stay out of such decisions. Middleware's job
is to handle application optimization, etc. so that the end consumer
stays as ignorant as possible thus focused on their application's needs
not the networks. The middleware API - whether DAPL, IT API, RNIC
PI, whatever - can provide the hooks needed to manage the usage from a
given endnode's perspective. But even here, the real network
management, what routes are actually used, the arbitration for QoS, etc.
should also be outside of the middleware's control. It simply
manages a set of local resources and allows the fabric management to do
the rest. There is more to this than that but that is how IB was
constructed which is no different in many respects from how IP works as
well.<br><br>
Mike</font></body>
</html>