Revision history   OpenPOWER Library

 Chapter 4. Programming Models

 The Coherent Accelerator Interface Architecture (CAIA) defines several programming models for virtualization of an acceleration function unit (AFU):

  •  Dedicated-process programming model (no AFU virtualization)

  •  Shared programming models, which include these two types:

    •  PSL-controlled shared programming models (AFU time-sliced virtualization)

    •  AFU-directed shared programming models (AFU-controlled process element selection virtualization)


 The AFU-directed programming model, where the AFU selects a context from the process element linked list to use for a transfer, is intended for the Networking and Storage market segments. For these types of applications, the required address context is selected based on a packet received from a network or which process is accessing storage. A CAIA-compliant device can also act as system memory or the lowest point of coherency (LPC). In this model, the process element and address translation are not required. The LPC model can also be used in combination with the other programming models but might not be supported by all devices.

 In the dedicated process model, the AFU is dedicated to a single application or process under a single operating system (partition[1]). The single application can act as an "Application as a Service" and funnel other application requests to the accelerator, providing virtualization within a partition.

 In the PSL-controlled shared and AFU-directed shared programming models, the AFU can be shared by multiple partitions. The shared models require a system hypervisor to virtualize the AFU so that each operating system can access the AFU. For single-partition systems not running a hypervisor, the AFU is owned by the operating system. In both cases, the operating system can virtualize the AFU so that each process or application can access the AFU.

 For the AFU-directed shared programming model, the AFU selects a process element using a process handle. The process handle is an implementation-specific value provided to the host process when registering its context with the AFU (that is, calling system software to add the process element to the process element linked list). While the process handle is implementation specific, the lower 16-bits of the process handle must be the offset of the process element within the process element linked list.

 The "process element" contains the process state for the corresponding application. The work element descriptor (WED) contained in the process element can be a single job requested by an application or it can contain a pointer to a queue of jobs. In the latter case, the WED is a pointer to the job request queue in the application's address space.

 This document does not cover all aspects of the programming models. The intent of this section is to provide a reference for how the AFUs can be shared by all or a subset of the processes in the system . This section defines the infrastructure for setting up the process state and sending a work element descriptor (WED) to an AFU to start a job in a virtualized environment. The function performed by an AFU is implementation dependent.

[1] A partition is a single operating-system image. There can be multiple operating-system images running on a system. They can be of the same type (Linux) or of different types (Linux, AIX, other).

loading table of contents...