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
_______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
