Filter
Top Products
Intel
®
EP80579 Software for Security Applications on Intel
®
QuickAssist Technology
August 2009 PG
Order Number: 320183-004US 45
Programming Model—Security Software
Because it is blocking, synchronous mode should not be used in contexts where
blocking is not allowed, for example in interrupt context on Linux.
10.3.4 Pre-Registration
In a number of accelerator use cases, the concept of a session applies. A session
consists of a setup, multiple data phases and a tear down. The data phases are
typically long lived (with respect to session setup time); as a result there is a class of
API that requires registration. For example, symmetric cryptographic operations can
benefit from pre-registration. Data which is common to all operations can be provided
and/or pre-computed at session initialization time.
Alternately, there are scenarios where all the required data for a call are available at
the time of the call. These do not require pre-registration of a session.
10.4 Other API Conventions
Note: This section discusses conventions for APIs which are not part of the Intel
®
QuickAssist
Technology program, such as [DEBUG_API].
The “other” Acceleration APIs use some common conventions and share a common
programming model, which is loosely based on [NPF API]. Some of the key differences
between the NPF conventions and those adopted by the Acceleration APIs are
summarized below.
• Callback registration is not required, as described in Section 10.4.1
• Memory allocation and ownership is clarified, as described in Section 10.4.2
• Callback data structures are clarified, as described in Section 10.4.3
10.4.1 Asynchronous API and Function Completion Callbacks
Similar to what is described in Section 7 of [NPF API], most of the Acceleration APIs are
asynchronous. Completion of the work associated with an API function call is indicated
not by the return of the function, but by the invocation of a separate completion
callback function by the callee to the caller. This can be thought of as a request/
response mechanism. Such an asynchronous API allows for greater parallelism to be
achieved, while still allowing synchronous behavior to be easily layered on top of the
asynchronous callbacks if desired.
This asynchronous request/response model is suitable for an architecture such as the
EP80579 security software’s, where requests to perform cryptographic or other
operations can be sent to dedicated on-chip accelerators, and then responses received
when the operation is complete. The requests and responses are typically sent via
rings, as described in Chapter 2.0, “Silicon Overview.”
The key differences between the conventions adopted by the Acceleration APIs versus
those described in [NPF API] are as follows:
• Callback registration (and de-registration) is not required. The complexity imposed
on applications to manage callback handles was judged to outweigh any potential
benefits. As a result of this:
— Instead of passing a callback handle to every asynchronous function on the
Acceleration APIs, a function pointer is passed in.
— There is only one type of application context information, namely the correlator
which is provided at API function call time. The user context, which is provided
at callback registration time in the NPF model, is not required.