The POWER9™ processor-based servers support on-chip accelerators that perform various functions such as compression, decompression, encryption, and decryption of data. This accelerator can implement GZIP functions, for example, GZIP compression and decompression operations.
Applications in an AIX logical partition can access the GZIP accelerator by using the zlib interface. Starting from IBM® AIX® 7.2 with Technology Level 4, applications can access GZIP accelerator by using the zlibNX library. Based on environment variables and availability of a GZIP accelerator, the zlibNX library uses the hardware accelerated compression and decompression functions, when appropriate.
The hardware accelerators are shared between multiple logical partitions. Therefore, a flow control mechanism is required to prevent the logical partitions from using more than the allocated amount of the accelerator. This flow control mechanism is based on an allocation unit called credit. Credits are allocated to each logical partition. Before the zlibNX library can send an access request to the GZIP accelerator for an application, the zlibNX library must open a communication channel with the GZIP accelerator. An available credit is required to open a communication channel with the GZIP accelerator. Otherwise, the request fails.
An accelerator request on a communication channel takes up the associated credit and the credit is restored when the accelerator operation is complete. Thus, only one operation can be active at a time on a communication channel.
- Each logical partition has a number of default credits based on the CPU entitlement
of the logical partition.
If a communication channel uses a default credit, you cannot ensure whether an accelerator request will be successful. Based on the total number of requests that are currently being served by the accelerator, the accelerator request might fail and must be resubmitted later.
- In addition to the default credits, the system administrator can allocate a number of
quality of service (QoS) credits.
If a communication channel uses a QoS credit, the accelerator will always process an accelerator request if no other request is already in progress on the communication channel.
The management of the protocol with the GZIP accelerator, which includes opening a communication channel, generating and sending accelerator requests, and closing the communication channel, is handled by the zlib interface based on the inflate or deflate requests from the application.
New subroutines allow privileged applications to reserve QoS credits for exclusive use by the calling process and release those reserved credits when the credits are not required. These reserved credits are used by the zlib interface to open a communication channel and send accelerator requests to the GZIP accelerator unit. The number of accelerator requests that can be served concurrently is controlled by the number of reserved credits. Default credits cannot be reserved for exclusive use.
- A shared QoS credit that is not reserved, if available
- A default credit, if available
If no credits are available, the accelerator request is processed completely by software without any hardware acceleration.
- Returns 1 if a logical partition has access to a GZIP accelerator, otherwise, returns 0. This macro is defined in the <sys/systemcfg.h> header file.
- Returns the current generation count for the configuration data of the GZIP accelerator. Returns 0 if a GZIP accelerator is not available or is not configured. This macro is defined in the <sys/nx.h> header file.
The generation count is incremented every time that an operation changes the number of available credits for applications. For example, when a privileged application reserves or releases QoS credits or when QoS credits are being dynamically added or removed from the logical partition. A change in the generation count prompts the applications that track the number of available credits to refresh its configuration data by calling the nx_config_query subroutine.
Currently, only the GZIP accelerator is accessible to applications. However, the new subroutines take the accelerator type as an argument to extend this interface to other accelerator types in the future.