[openib-general] Re:[ULP] how to choose appropriate ULPs for application

[Michael Krause]

At 06:39 AM 7/13/2005, James Lentini wrote:


>On Tue, 12 Jul 2005, xg wang wrote:
>
>>     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.
>
>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.

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.


>kDAPL is the kernel Direct Access Provider Library. It is an API that 
>supports RDMA networks (InfiniBand, iWARP, etc.).
>
>>     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.
>
>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.
>
>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.

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.

>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.

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.

Mike 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20050713/3059de5f/attachment.html>