gtpm3m0jMulti-Processor Interconnect Facility Reference

Pacing Control

In order to avoid performance impacts to TPF, core blocks must be available for MPIF to dispatch requests for processing by defined user exits. If there are no blocks, no reads will be scheduled by MPIF. This is purposefully unfriendly: user functions should be designed to avoid such conditions when appropriate. The pacing facilities provided by MPIF can help.

When multiple copies of the same code (for example, multiple TPF routers) are going to communicate (HOMOGENEOUS connections), the code can be easily designed to use a protocol that avoids flooding a system with more SENDs than it has core blocks to support. For example, a protocol that is SEND, then wait for RECEIVE does not overrun either side's core block lists.

When a system service is providing a general facility and other system services can connect to it (HETEROGENEOUS connections), things get more difficult. While the system service providing the general facility can define a protocol that must be used by its users, it cannot prevent a user from violating the protocol (it can only punish users for violations). A user violating the protocol can impact other connections to the general purpose system service.

Prevent Buffer Overruns

The MPIF pacing facility provides a simple mechanism to help prevent buffer overrun conditions and to enforce this prevention. It allows each side of a connection to specify the maximum number of its buffers that the other side can consume before it is forced to stop SENDing on a specific connection. MPIF maintains a pacing credit count and when credit is exhausted, SENDs from that side of the connection are stopped. The receiver is able to increase the sender's pacing credit count, by providing the sender with credit with messages sent to the sender. Thus the receiver is able to control the number of the receiver's core blocks consumed by the sender. When options are defaulted, each time the receiver SENDs to the other side, the other side's pacing credit count is incremented by one (credited with 1). This default supports protocols that are rigidly one-in, one-out as well as protocols that are many-in, many-out with an equal number out.