Check out the new USENIX Web site. next up previous
Next: Zero-Copy Reply Handling Up: Page Transfers in GMS/Trapeze Previous: Page Transfers in GMS/Trapeze

Basic Mechanisms

The gms_net messaging layer includes basic support for typed messages, stub procedures, dispatching to service procedures based on message types, and matching replies with requests. The Trapeze receiver interrupt handler directs incoming messages to gms_net by upcalling a registered service routine; the service routine hands off incoming requests to a server thread. However, gms_net it is not a true RPC system: many protocol messages do not produce replies, and there is no support for automatic stub generation. The package is best thought of as a library of procedures and macros used by the messaging stubs to build and decode messages and to direct their flow through the system. It is designed for messages with relatively simple arguments and bulk data payloads (e.g., file blocks) that are not interpreted by the message handlers themselves.

To send a message, a stub allocates a message buffer with gms_net_makebuf, calls routines and macros to build the message, e.g., by pushing data items into the message, and sends the message to a destination with gms_net_sendto. In Trapeze, gms_net_makebuf returns a pointer to a send ring entry, and gms_net_sendto releases it. Messages are typed by an operation code and a request/reply bit. Incoming requests are dispatched by using the operation code to index into a vector of registered server-side stubs. Incoming replies are handled directly by the receiver interrupt handler, either by waking up a waiting thread or by calling a reply continuation procedure as described in Section 3.4.

An important function of the RPC layer is to match incoming replies with requests. If a reply is expected, the caller makes an entry in a call record table before sending the request message, and places a reply token containing a unique call record ID into the outgoing request message. After sending the request, the calling thread or process may block on the call record entry. When the server side generates a reply, it places a copy of the reply token in the reply message. When the reply arrives, the receiver interrupt handler decodes the reply token and retrieves the call record. The call record includes all information needed to process the reply, e.g., by awakening the calling thread or process.

To transfer a page or file block in a request or reply, the stub attaches the memory frame to the message buffer as a payload. The system is inhibited from reusing the frame or overwriting it until the frame contents have been transferred to the network adapter using DMA (Section 2.2). On the receiving side, Trapeze uses DMA to deposit each received payload into a memory frame designated by the receiver.


next up previous
Next: Zero-Copy Reply Handling Up: Page Transfers in GMS/Trapeze Previous: Page Transfers in GMS/Trapeze
Darrell Anderson
1998-04-27