Intel EP80579 User Manual

Intel

®

 EP80579 Software for Security Applications on Intel

®

 QuickAssist Technology

August 2009

PG

Order Number: 320183-004US

45

Because it is blocking, synchronous mode should not be used in contexts where 

blocking is not allowed, for example in interrupt context on Linux.

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.

This section discusses conventions for APIs which are not part of the Intel

®

 QuickAssist 

Technology program, such as 

. 

The “other” Acceleration APIs use some common conventions and share a common 

programming model, which is loosely based on 

. 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 

• Memory allocation and ownership is clarified, as described in 

• Callback data structures are clarified, as described in 

Similar to what is described in Section 7 of 

, 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 

The key differences between the conventions adopted by the Acceleration APIs versus 

those described in 

• 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.