next up previous contents
Next: Implementation issues Up: Implementations Previous: Multithreaded Implementation   Contents


LAPI Implementation

The Low-level Application Programming Interface (LAPI) is a low level communication interface for the IBM Scalable Powerparallel (SP) supercomputer Switch. This switch provides scalable high performance communication between SP nodes. The LAPI is a non-standard application programming interface and provides efficient one-side communication performance between tasks on IBM SP system. LAPI offers better message passing performance than MPI on small and medium size messages. However users must write many extra lines of low-level communication calls on their applications. The target group of LAPI is power programmers who need performance improvement more than code portability.

LAPI functions can be divided into three different characteristic groups. The first of these is a basic active message infrastructure that allows programmers to write and install their own set of handlers that are invoked and executed in a target process on behalf of the process originating the active message. The active messages play important role in implementation of our underlying communication. In addition to the active message, the LAPI provides a Remote Memory Copy (RMC) interface--including a PUT operation that copies data from the address space of the origin process into the address space of the target process and a GET operation which is opposite of the PUT operation. LAPI also provides a set of control functions for the initialization and termination of the LAPI layer.

Figure 5.14: LAPI Active Message Call.
\includegraphics[width=6.6in height=3in]{Figs/lapi.eps}
The active message function (LAPI_Amsend) is a basic programming mechanism that provides a one-sided communications model. It is a non-blocking call on the origin process that causes a specified active message handler to be invoked and executed in the address space of the target process. The basic communication model of the active message function is given in Figure 5.14. Different steps of communication functions are involved within an active message call. Each active message includes the address of a user-specified handler and it may optionally bring a user header and data from the origination process (step 1). Once the first packet of the message arrives at the target process. The LAPI dispatcher, which is the part of the LAPI that deals with the arrival of message and invocation of handlers, invokes a header handler (step 2). A header handler is responsible for the address of where to copy the arriving data, the address of the optional completion handler, and a pointer to the parameter that is to passed to the completion hander (step 3). The completion handler is executed after the last packet of the message has been received and copied into a buffer (step 4).

To ensure reusability of buffer on completion of data transfer, the active message uses three counters. Two counters (origin counter and completion counter) are located in the address space of sending task and one counter (target counter) is located in the target task's address space. The origin counter is incremented when it is safe for the origin task to update the origin buffer. After the message has arrived at the target task, the target counter is incremented. Completion of the message transfer updates the completion counter. We can simulate blocking communication by waiting for the completion counter to increment.



Subsections
next up previous contents
Next: Implementation issues Up: Implementations Previous: Multithreaded Implementation   Contents
Bryan Carpenter 2004-06-09