Hardware acceleration of data reduction operations

Abstract

A hardware acceleration device is equipped with circuitry to perform one or more reversible data transformations on data based on a request and compress the transformed data to produce compressed transformed data. The hardware acceleration device generates an output containing the compressed transformed data and transformation metadata indicating the set of reversible data transformations applied to the compressed transformed data.

Description

TECHNICAL FIELDThe present disclosure relates generally to the field of distributed computing systems, and more particularly to the application of reversible data transformations using a hardware accelerator.BACKGROUNDA data center may include one or more platforms, each including at least one processor and associated memory modules. Each platform of the data center may facilitate execution of any number of processes associated with various applications running on the platform. These processes may be performed by the processors and other associated logic on the platforms. Each platform may additionally include I / O controllers, such as network adapters, that may be used to send and receive data over a network for use by the various applications.BRIEF DESCRIPTION OF THE DRAWINGSFIG. 1 shows a block diagram of components of a data center in accordance with certain embodiments. FIG. 2 is a simplified block diagram of an example platform with a hardware accelerator. FIG. 3 is a simplified block diagram illustrating an example logical stack for a hardware accelerator used by one or more applications in an example computing platform. FIG. 4 is a simplified block diagram showing an example data transformation and compression process. FIG. 5 is a simplified block diagram showing an example linked list of data transformations to be included in a data reduction request. FIG. 6 is a simplified block diagram showing example inputs of an example hardware accelerator. FIG. 7 is a simplified block diagram showing an example decompressing operation. Figure 8 is a simplified block diagram illustrating the exemplary application of a sequence of data transformations and corresponding reverse data transformations. FIG. 9 is a simplified block diagram showing an example data transformation and a corresponding inverse data transformation. FIG. 10 is a flow chart illustrating example techniques for performing data reduction using a hardware accelerator and performing corresponding data recovery. FIG. 11 shows a block diagram of an example processor unit, in accordance with certain embodiments.Like reference numerals and designations in the various drawings designate like elements.DETAILED DESCRIPTIONFIG. 1 shows a block diagram of the components of a data center 100, in accordance with certain embodiments. In the illustrated embodiment, data center 100 includes a plurality of platforms 102, a data analysis engine 104, and a data center management platform 106 interconnected via a network 108. A platform 102 may include platform logic 110 having one or more central processing units (CPUs) 112, memory 114 (which may include any number of different modules), chipsets 116, communication interfaces 118, and other suitable hardware and / or software to execute a hypervisor 120 or other operating system capable of executing processes associated with applications running on the platform 102. In some embodiments, a platform 102 may function as a host platform for one or more guest systems 122 that invoke these applications. The platform may be logically or physically divided into clusters, and these clusters may be enhanced by, among other things, specialized network accelerators and the use of compute express link (CXL) memory semantics to increase the efficiency of such clusters.Each platform 102 may include platform logic 110. Platform logic 110 includes, among other things, logic that enables the functionality of platform 102, one or more CPUs 112, memory 114, one or more chipsets 116, and communication interfaces 118. Although three platforms are shown, data center 100 may include any number of platforms. In various embodiments, a platform 102 may be located on a circuit board installed in a chassis, rack, potential servers, disaggregated servers, or other suitable structures including multiple platforms interconnected via a network 108 (e.g., which may include a rack or backplane switch). In further examples, the platform or portions of the platform (including a pre-processing hardware accelerator (e.g., 150)) may be incorporated into other computing systems and form factors, including personal computers, set-top boxes, gaming systems, smart devices, IoT systems, smart phones, vehicle onboard systems, and other examples.The CPUs 112 may each include any number of processor cores. The cores may be coupled to each other, to memory 114, to at least one chipset 1016, and / or to a communication interface 118 through one or more controllers residing on CPU 112 and / or chipset 1016. In certain embodiments, a CPU 112 is formed in a socket that is permanently or removably coupled to the platform 102. Although four CPUs are illustrated, a platform 102 may include any suitable number of CPUs. In some implementations, the applications to be executed with the CPU (or other processors) may include physical layer management applications that enable customized software-based configuration of the physical layer of one or more connections used to couple the CPU (or associated processor devices) to one or more other devices in a data center system.The memory 114 may include, without limitation, any form of volatile or non-volatile memory, magnetic media (e.g., one or more tape drives), optical media, random access memory (RAM), read only memory (ROM), flash memory, removable media, or any other suitable local or remote storage component or components. The memory 114 may be used for short, medium, and / or long term storage from the platform 102. The memory 114 may store any suitable data or information utilized by the platform logic 110, including software integrated with a computer readable medium and / or hardware-incorporated or otherwise stored encoded logic (e.g., firmware). The memory 114 may store data used by cores of the CPUs 112. In some embodiments, the memory 114 may also store instructions executable by the cores of the CPUs 112 or other processing elements (e.g., logic on the chipsets 116) to provide the functions associated with the components of the platform logic 110. Additionally or alternatively, chipsets 116 may each include memory, which may include all of the characteristics of memory 114 described herein. The memory 114 may also store the results and / or intermediate results of the various computations and determinations performed by the CPUs 112 or the processing elements on the chipset 116. In various embodiments, memory 114 may consist of one or more modules of system memory that are connected to the CPUs via memory controllers (which may be external or integrated into CPUs 112). In various embodiments, one or more particular modules of memory 114 may be associated with a particular CPU 112 or other processing device or shared among multiple CPUs 112 or other processing devices.A platform 102 may also include one or more chipsets 116, which may include any suitable logic to support the operation of the CPUs 112. In various embodiments, chipset 116 may be located on the same chassis as CPU 112 or on one or more different chassis. Each chipset may support any suitable number of CPUs 112. A chipset 116 may also include one or more controllers to couple other components of platform logic 110 (e.g., communication interface 118 or memory 114) to one or more CPUs. Additionally or alternatively, the CPUs 112 may include integrated controllers. For example, the communication interface 118 could be directly connected to the CPUs 112 via integrated I / O controllers present in each CPU.Chipsets 116 may each include one or more communication interfaces 128. The communication interface 128 may be used for communication of signals and / or data between the chipset 116 and one or more I / O devices, one or more networks 108, and / or one or more devices connected to the network 108 (e.g., the data center management platform 106 or the data analytics engine 104). For example, communication interface 128 may be used to transmit and receive network traffic, such as data packets. In a particular embodiment, the communication interface 128 may be implemented by one or more I / O controllers, such as one or more physical network interface controllers (NICs), also known as network interface cards or network adapters. An I / O controller may include electronic circuitry to communicate via any suitable physical layer and data link layer standard, such as Ethernet (e.g., according to IEEE 802.3 standard), Fibre Channel, InfiniBand, Wi-Fi, or other suitable standards. An I / O controller may include one or more physical ports that may be connected to a cable (e.g., an Ethernet cable). An I / O controller may enable communication between any suitable element of chipset 116 (e.g., switch 130) and another device connected to network 108. In some embodiments, the network 108 may include a switch having bridging and / or routing functions that is external to the platform 102 and is operable to interconnect various I / O controllers (e.g., NICs) distributed throughout the data center 100 (e.g., on different platforms). In various embodiments, an I / O controller may be integrated into the chipset (i.e., may reside on the same integrated circuit or circuit board as the rest of the chipset logic), or may reside on another integrated circuit or circuit board electromechanically coupled to the chipset. In some embodiments, communication interface 128 may also enable communication of platform-integrated or external I / O devices (e.g., hard disk drives, other NICs, etc.) with the CPU cores.The switch 130 may be coupled to various ports (e.g., NICs) of the communication interface 128 and may switch data between those ports and various components of the chipset 116 according to one or more connection or interconnect protocols, such as peripheral component interconnect express (PCIe), compute express link (CXL), HyperTransport, GenZ, OpenCAI, and others, each of which may alternatively or jointly employ the general principles and / or specific features discussed herein. The switch 130 may be configured as a physical or virtual switch (i.e., software).Platform logic 110 may include an additional communication interface 118. Similar to the communication interfaces 128, the communication interfaces 118 may be used for communicating signals and / or data between the platform logic 110 and one or more networks 108 and one or more devices coupled to the network 108. For example, communication interface 118 may be used to transmit and receive network traffic, such as data packets. In a particular embodiment, the communication interface 118 includes one or more physical I / O controllers (e.g., NICs). These NICs may enable communication between any suitable element of platform logic 110 (e.g., CPUs 112) and another device connected to network 108 (e.g., elements of other platforms or remote nodes connected to network 108 via one or more networks). In certain embodiments, the communication interface 118 may enable off-platform devices (e.g., hard disk drives, other NICs, etc.) to communicate with the CPU cores. In various embodiments, the NICs of the communication interface 118 may be connected to the CPUs via I / O controllers (which may be external or integrated with the CPUs 112). Additionally, as described herein, I / O controllers may include a power manager 125 to implement functions to manage power consumption at the I / O controller (e.g., by automatically implementing power savings at one or more interfaces of the communication interface 118 (e.g., a PCIe interface connecting a network card to another element of the system), among other example functions.Platform logic 110 may receive and execute all suitable types of processing requests. Requested processing may include any request to use one or more resources of platform logic 110, such as one or more cores or associated logic. A processing request may include, for example, a processor core interrupt, a request to instantiate a software component, such as an I / O device driver 124 or a virtual machine 132, a request to process a network packet received from a virtual machine 132 or a device external to the platform 102 (such as a network node connected to the network 108), a request to execute a workload (e.g., a process or thread) connected to a virtual machine 132, an application running on the platform 102, a hypervisor 120, or another operating system running on the platform 102, or another suitable request.In various embodiments, processing requests may be associated with guest systems 122. A guest system may include a single virtual machine (e.g., virtual machine 132 aor 132 b) or multiple virtual machines that operate together (e.g., a virtual network function (VNF) 134 or a service function chain (SFC) 136). As shown, various embodiments may include a plurality of types of guest systems 122 on the same platform 102.A virtual machine 132 may emulate a computer system with its own dedicated hardware. A virtual machine 132 may execute a guest operating system on the hypervisor 120. The components of platform logic 110 (e.g., CPUs 112, memory 114, chipset 116, and communication interface 118) may be virtualized to appear to the guest operating system to have virtual machine 132 with its own dedicated components.A virtual machine 132 may include a virtualized NIC (vNIC) used by the virtual machine as its network interface. A vNIC may be assigned a media access control (MAC) address such that multiple virtual machines 132 in a network are individually addressable.In some embodiments, a virtual machine 132 bmay be paravirtualized. For example, virtual machine 132 bmay include enhanced drivers (e.g., drivers that provide higher performance or have higher bandwidth interfaces to the underlying resources or capabilities provided by hypervisor 120). For example, an enhanced driver may have a faster interface to the underlying virtual switch 138 to achieve higher network performance compared to standard drivers.VNF 134 may include a software implementation of a functional building block with defined interfaces and behavior that may be deployed in a virtualized infrastructure. In certain embodiments, a VNF 134 may include one or more virtual machines 132 that collectively provide specific functionalities (e.g., wide area network (WAN) optimization, virtual private network (VPN) termination, firewall operations, load balancing operations, security functions, etc.). VNF 134 running on platform logic 110 may provide the same functionality as traditional network components implemented by dedicated hardware. For example, a VNF 134 may include components to perform any suitable NFV workloads, such as virtualized evolved packet core (vEP) components, mobility management entities, 3rd generation partnership project (3GPP) control, and data plane components, etc.SFC 136 is a group of VNFs 134 organized as a chain to perform a series of operations, such as network packet processing operations. Service function chaining may provide the ability to define an ordered list of network services (e.g., firewalls, load balancers) stitched together in the network to generate a service chain.A hypervisor 120 (also known as a virtual machine monitor) may include logic to generate and execute guest systems 122. The hypervisor 120 may provide guest operating systems executing virtual machines with a virtual operating platform (i.e., the virtual machines appear to run on separate physical nodes when they are actually consolidated on a single hardware platform) and manage the execution of the guest operating systems by platform logic 110. Services of hypervisor 120 may be provided by virtualizing in software or by hardware-supported resources, or both, that require minimal software intervention. Multiple instances of a plurality of guest operating systems may be managed by the hypervisor 120. Each platform 102 may have a separate instantiation of a hypervisor 120.The hypervisor 120 may be a native or software independent hypervisor running directly on the platform logic 110 to control the platform logic and manage the guest operating systems. Alternatively, the hypervisor 120 may be a hosted hypervisor that runs on a host operating system and abstracts the guest operating systems from the host operating system. Various embodiments may include one or more non-virtualized platforms 102, in which case all suitable features or functions of hypervisor 120 described herein may apply to an operating system of the non-virtualized platform.The hypervisor 120 may include a virtual switch 138, which may provide virtual switching and / or routing functions to the guest system virtual machines 122. The virtual switch 138 may have a logical switching structure that couples the vNICs of the virtual machines 132 together, thus creating a virtual network through which the virtual machines may communicate with each other. Virtual switch 138 may also be connected to one or more networks (e.g., network 108) via physical NICs of communication interface 118 to enable communication between virtual machines 132 and one or more network nodes external to platform 102 (e.g., a virtual machine running on another platform 102 or a node connected to platform 102 via the Internet or other network). The virtual switch 138 may include a software element that is executed using components of the platform logic 110. In various embodiments, the hypervisor 120 may be in communication with any entity (e.g., an SDN controller), which may cause the hypervisor 120 to reconfigure the parameters of the virtual switch 138 in response to changing conditions in the platform 102 (e.g., the addition or deletion of virtual machines 132 or the identification of optimizations that may be made to increase the performance of the platform).The hypervisor 120 may include any number of I / O device drivers 124. I / O device driver 124 represents one or more software components that enable hypervisor 120 to communicate with a physical I / O device. In various embodiments, the underlying physical I / O device may be connected to one of the CPUs 112 and send data to the CPUs 112 and receive data from the CPUs 112. The underlying I / O device may use any suitable communication protocol, e.g., PCI, PCIe, Universal Serial Serial Bus (USB), Serial Attached SCSI (SAS), Serial ATA (SATA), InfiniBand, Fibre Channel, an IEEE 802.3 protocol, an IEEE 802.11 protocol, or another current or future signaling protocol.The underlying I / O device may include one or more ports that may be used for communication with the cores of the CPUs 112. In one example, the underlying I / O device is a physical network card or switch. In one embodiment, the underlying I / O device of the I / O device driver 124 is, for example, a NIC of the multi-port communication interface 118 (e.g., Ethernet ports).In other embodiments, the underlying I / O devices may include any suitable device capable of transmitting and receiving data to and from the CPUs 112, such as an audio / video device controller (e.g., a graphics accelerator or audio controller), a data storage controller such as flash memory, a magnetic disk or optical disk controller, a wireless transceiver, a network processor, or a controller for another input device such as a monitor, printer, mouse, keyboard, or scanner, or other suitable device.In various embodiments, upon receipt of a processing request, the I / O device driver 124 or the underlying I / O device may send an interrupt (e.g., an interrupt signaled by a message) to one of the cores of the platform logic 110. For example, the I / O device driver 124 may send an interrupt to a core that has been selected to perform an operation (e.g., on behalf of a virtual machine 132 or a process of an application). Before the interrupt is forwarded to the core, incoming data (e.g., network packets) destined for the core may be cached in the underlying I / O device and / or an I / O block connected to the core's CPU 112. In some embodiments, the I / O device driver 124 may configure the underlying I / O device with instructions about where interrupts are to be sent.In some embodiments, when distributing workloads to the cores, the hypervisor 120 may route a greater number of workloads to the more powerful cores than to the less powerful cores. In certain cases, cores that have problems such as overheating or heavy load may be entrusted or entirely avoided (at least temporarily) with less tasks than other cores. Workloads associated with applications, services, containers, and / or virtual machines 132 may be distributed among the cores based on network load and traffic patterns, and not just CPU and memory usage metrics.The elements of platform logic 110 may be coupled together in any suitable manner. For example, a bus may couple any of these components together. A bus may include any known interconnect, such as a multi-station bus, a mesh interconnect, a ring interconnect, a point-to-point interconnect, a serial interconnect, a parallel bus, a coherent bus (e.g., cache coherent), a layered protocol architecture, a differential bus, or a Gunning Transceiver Logic (GTL) bus.The elements of the data system 100 may be interconnected in any suitable manner, such as via one or more networks 108. A network 108 may be any suitable network or combination of one or more networks operating using one or more suitable network protocols. A network may represent a series of nodes, points, and connected communication paths for receiving and transmitting information packets transmitted by a communication system. For example, a network may include one or more firewalls, routers, switches, security applications, anti-viral servers, or other useful network devices. A network provides communication interfaces between sources and / or hosts, and may include a local area network (LAN), a wireless local area network (WLAN), a metropolitan area network (MAN), an intranet, an extranet, the Internet, a wide area network (WAN), a virtual private network (VPN), a cellular network, or other suitable architecture or system that facilitates communication in a network environment. A network may consist of any number of hardware or software elements interconnected (and communicating with each other) via a communication medium. In various embodiments, guest systems 122 may communicate with nodes external to data center 100 via network 108.In some implementations, the data system 100 may include one or more hardware accelerator devices (e.g., 150) to support the tasks of the data system 100 and "accelerate" certain general tasks of the system 100 to increase the overall efficiency of the system and applications running on the system (e.g., in terms of latency, bandwidth, or energy). In one example, the data system 100 may be equipped with a preprocessing accelerator device 150 having hardware implemented logic to perform a variety of functions or algorithms commonly used in the data system. For example, preprocessing accelerator 150 may include circuitry for performing compression / decompression, encryption / decryption, and other tasks, including the application of data transformations as further discussed herein. The exponential growth of data and compute intensive workloads such as artificial intelligence (AI), analytics, high-performance storage, and cloud application services places ever-increasing demands on the CPU(s) of a data system and other hardware (e.g., memory, I / O, etc.). For example, management of encrypted data resources has become common practice. In addition, applications where data is compressed and encrypted in a single pass can place severe stress on processing resources and result in bottleneck in the data flow, which in turn increases latency. Even standard compression algorithms can consume substantial CPU resources. To solve these and other problems, a pre-processing accelerator may be incorporated (e.g., as a stand-alone accelerator device, an incorporated accelerator, or an add-on card) that may offload certain computational intensive operations (e.g., symmetric and asymmetric cryptography, data compression / decompression operations, data transformations, etc.) from the CPU, such that computational resources may be reallocated to allow the CPU to perform other tasks more efficiently, which may improve overall system performance, efficiency, and power consumption in various use cases, among others.Modern computing systems encounter increasing demands on their memory and communication bandwidth because they are entrusted with communication, buffering, and processing of larger and larger amounts of data of different types. For example, in Internet of Things (IoT) applications, time-series data may be generated from various IoT sensors, event protocols, web or mobile analytics, enterprise servers, and other sources and stored in specific time-series databases tailored to such data. Column-based databases include, for example, highly typified records such as INT, FLOAT, DATA, TIME, etc. In some implementations, the data in these databases is stored in a compressed format to efficiently manage the data. Various compression algorithms can be used to perform such compressions, including LZ77 algorithms such as ZSTD, LZ4, Snappy, and other examples. When compression is performed by a CPU (e.g., before the data is moved to memory or transferred over a bus or network interface), large amounts of data are typically transferred to / from the CPU cache in which the data is stored while performing the compute-intensive compression transformations. The faster the computation, the less the cache dwell time and the better the cache is used. Accordingly, the acceleration of compression algorithms in the hardware significantly reduces the latency of the entire compression process, leading to, among other things, a reduction in CPU computational cycles and a better cache utilization.In addition to improving CPU and overall system performance, reversible transformation operations may be incorporated into a hardware accelerator. Given the constant need to reduce data demand, the integration of reversible transformations that make the data more suitable for subsequent compression is a powerful approach to further reduce data demand within a system and to achieve further gain in efficiency. However, reversible data transformations are also computationally intensive and typically require that an entire data set be processed before the "transformed" data set can be compressed, thereby increasing overall latency as well as utilization of cache and CPU cycles. In conventional systems, reversible data transformations are implemented in software and the results of the transformations are then passed to compression software or hardware. Some examples of reversible data transformations include integer transformations (e.g., delta, double delta transformations, gorilla (XOR transformation), bit shuffle, byte shuffle, T64 (e.g., removing the unused most significant bits, etc.), floating point transformations (e.g., gorilla (XOR transformation), etc.), text transformations (e.g., Burrows-Wheeler transformation, move-to-front, etc.), and other examples. In an improved preprocessing accelerator, the accelerator's computational circuitry may implement a set of reversible transformations to enable the entire operation to be accelerated as a single pipelined operation. Such a solution provides data footprint optimizations without increasing the associated CPU cycle cost, compression latency, or cache utilization, to name a few examples.Traditionally, the implementation of reversible transformations has been a domain of software where software solutions have relied on to perform various preprocessing tasks, including compression and decompression. As far as systems perform compression / decompression together with a reversible transformation, such solutions have been implemented as two independent functions. Accordingly, conventional solutions have the disadvantage of having higher memory bandwidth, higher latency, higher CPU cycle cost, and lower cache utilization to achieve a higher compression rate. Some solutions use software to perform a data transformation and to pass the transformed data to a hardware-based compression engine. Likewise, the inverse transformation after decompression may be performed by a hardware or software based decompressing engine via software. However, a disadvantage of this approach is again the higher latency, more CPU cycles, and additional I / O operations to / from the cache, among other examples.In an improved data processing system, a hardware accelerator with built-in support for both reversible data transformation operations and compression operations may be provided. The accelerator's data transform function may integrate corresponding preprocessing codes into a compression pipeline to enable, among other things, lower latency, better cache utilization, and lower memory bandwidth consumption. FIG. 2 shows a simplified block diagram 200 of an example processing device 205 implemented in, e.g., a system on chip (SoC), a processor device, a motherboard, or other computing platform. In this example, an improved preprocessing hardware accelerator 150 may be provided. The preprocessing hardware accelerator 150 may include circuitry (e.g., 210) to implement a set of data transformations and a corresponding set of reverse data transformations, as well as circuitry (e.g., 215) to perform compression and decompression of data according to one or more lossless compression algorithms. The hardware accelerator 150 may also provide other functions that may be used to pre-process (or post-process) data for the system, such as cryptographic operations and other examples. The hardware accelerator 150 enables these operations to be offloaded from general-purpose processing cores (e.g., CPUs), which could otherwise be prompted to perform such operations (e.g., by execution of appropriate software or firmware code). In this example, the computing system 205 may include multiple processors 220 a- fwith corresponding cache blocks 225 a- f(e.g., level 3 cache (L3)). System memory 230 a- b(e.g., using DDR4 memory blocks) may also be provided and utilized by processors 225 a- fand hardware accelerator 150, among other elements of the data processing system. In some implementations, source and destination buffers may be implemented in cache 225 a- for system memory 230 a- b. I / O circuits may be provided to connect components to memory 203 a- b. Additional I / O circuitry (e.g., 235, 240, 245, 250, 255, 265, 270, 275) may be provided to enable the data processing system 205 to communicate with external devices, e.g., via high speed flexible I / O lanes (HSIOs) 260.The simplified block diagram 300 of FIG. 3 shows a diagram of a logic stack for implementing applications (e.g., 310, 315, 330, 335) that may utilize the functionality of the preprocessing hardware accelerator 150. In some implementations, one or more application programming interfaces (APIs) may be provided that enable applications to request the hardware accelerator to perform one or a series of reversible data transformations and / or a lossless compression algorithm (e.g., immediately after the data transformations) using the hardware circuitry of the hardware accelerator 150. Some applications (e.g., 310) may directly access the accelerator API 305, while other applications (e.g., 315, 330, 335, etc.) Adapters (e.g., 320), shims (e.g., 325), open source APIs and adapters (e.g., 340, 345, 350), as well as other example functions and implementations may use.In an example implementation, the accelerator API 305 may define a compression API call to request transformation and compression operations of the hardware accelerator 150. In one example, the call to the compression API indicates the number of transformations (e.g., 0-15) and the order / granularity in which they are to be applied. The hardware accelerator may read transformation metadata and the source data to be transformed and compressed (e.g., from DRAM, cache, or a peer device) into the accelerator 150 in a request made via the call to the compression API. The circuitry of the hardware accelerator 150 analyzes the transform metadata to determine the transforms to apply, and then applies the indicated transform(s) in the order indicated by the application in the request (e.g., as programmed by an end user), and then compresses the transformed data with a compression circuitry (e.g., an LZ77 compressor) of the hardware accelerator 150. In some implementations, the hardware accelerator 150 may support multiple compression algorithms, and the requests provided via the compression API call may also indicate which of the supported compression algorithms is to be implemented. The transformed / compressed data and the associated (unchanged) transformation metadata may then be written to memory (e.g., DRAM), a peer device, database, or other destination.In the case of decompression / inverse transformations, a decompression API may be provided in the hardware accelerator API 305. In one example, the decompression API specifies the amount of (reverse) data transformations (e.g., 0-15) and the order / granularity in which they are to be applied. The decompression circuitry of the hardware accelerator 150 may read the transform metadata provided in a decompression request via the decompression API and the source data associated therewith to be decompressed (e.g., from the DRAM or a peer device) into the hardware accelerator 150. The hardware accelerator 150 may analyze the transform metadata to determine the (inverse) transforms to apply after decompression to restore the compressed and transformed data to its original state. The corresponding hardware circuit of the hardware accelerator 150 is then selected to first decompress the data in an appropriate manner and then reverse the transformations to restore the original data before the decompressed data is written to a destination (e.g., DRAM, a peer device, etc.).An enhanced preprocessing hardware accelerator (e.g., 150) may be implemented to perform a combined data reduction operation from one or more reversible data transformations followed by lossless compression in a single offload operation. Similarly, the preprocessing hardware accelerator (e.g., 150) may perform a combined data recovery operation including corresponding decompression and corresponding inverse data transformations in a single offload operation. The use of such a hardware accelerator allows valuable CPU cycles to be saved and reduces read and write cycles in memory (e.g., conventional software-based transformations and compressions require at least two passes) while improving cache utilization. In some cases, the preprocessing hardware accelerator may also include circuitry that executes a verification function to verify whether the decompressed data matches the original data, and a compression and verification function may also be performed in a single offload, among other examples.FIG. 4 shows a simplified block diagram 400 illustrating the general flow of a combined data reduction and recovery process using an improved preprocessing hardware accelerator. The hardware accelerator accesses the original data 405 (e.g., from a source buffer) and applies one or more contextual, reversible data transformations 410 to the data 405 (e.g., upon request via the hardware accelerator API). Once the data transform(s) is applied to the data 405, the transformed data may be provided as input to the hardware compression circuitry of the hardware accelerator to compress the transformed data. The resulting compressed data may be more compact due to the applied data transformations than if the data were compressed only by means of the compression circuit. The compressed data may be written to a destination (e.g., database 420 or other internal or external device). The compressed data may be accessed by the same or another system having an instance of the hardware accelerator to determine (e.g., from metadata attached to or otherwise associated with the compressed data) which data transformations were (optionally) performed and to decompress (at 425) the data before performing any reverse data transformations 430 based on the metadata to restore the data to the original data 405'. In order to manage the physical space requirement of the hardware accelerator, only limited amounts of data can be supplied to the hardware accelerator in each case in some cases. In this way, hardware accelerators may support multiple data transformations, wherein the circuits implementing the respective data transformation take up comparatively little space, since only relatively small data areas (e.g., less than 4 GB) are processed in each case. For example, the granularity of the data processed in a transform or inverse transform may be less than the granularity of the data processed in a compression or decompression (e.g., with a maximum compression request length of 4 GB), among other examples and considerations.In an example implementation, the list of transformations to be applied in a combined data reduction operation to be performed by a preprocessing hardware accelerator may be provided via an API-level linked list. For example, the linked list may identify the specific transformations to be applied (from the transformations supported by the hardware accelerator) along with the order in which the set of transformations is to be applied within the linked list. For example, FIG. 5 is a block diagram 500 showing at least a portion of an example implementation of a connection list included in a compression request conveyed by a call to the hardware accelerator API. In this example, each entry (e.g., 505, 510) in the linked list conveyed by the API call may include a first field (e.g., 515a-b) to designate (e.g., by a transformation identifier) the selected transformation, a second field (e.g., 520a-b) indicating the granularity of the transformation (e.g., 8-bit granularity, 16-bit granularity, 32-bit granularity, etc.), and the third field (e.g., 525a-b) next serving valid field to reference the next entry (e.g., 510) in the linked list. If the next valid field of a particular entry (e.g., 510) is a null value (or other value indicating that there are no other entries in the list), this means that the corresponding transform (e.g., as indicated in 515b) is the last transform performed on the data included in the API call. In some cases, no transformations are requested with a particular call to the compression API. In an example implementation, a NULL pointer may be passed in the API call when no transformations are requested for compression.In some implementations, a driver connected to the preprocessing hardware accelerator may receive the data and the linked link and convert the linked list to a transformation metadata structure that is appended to or otherwise connected to the data to be compressed. In an example, the length of the generated transformation metadata may be based on the number of transformations listed in the link list. FIG. 6 is a block diagram 600 illustrating examples of source buffers (e.g., 605, 610) that the preprocessing hardware accelerator can access to obtain the data to be transformed (e.g., 615) with the corresponding transformation metadata (e.g., 620) (e.g., as generated from a linked list (or other transformation request data) included in a compression API call). The preprocessing hardware accelerator may include logic (e.g., implemented in hardware circuits or firmware) to analyze the transformation metadata to detect whether to apply data transformations, which transformations are requested, and in what order the transformations are to be applied to the data 615 in the request. In one example, the determined transformations may be displayed in a firmware descriptor interface of the hardware accelerator. In some implementations, the source data 615 and the transformation metadata may be stored in a non-contiguous form, e.g., in a scatter gel list (SGL) buffer or other structure. For example, an SGL buffer 610 may be used that includes an SGL header 625 and pointers (e.g., 630, 635) to corresponding memory locations with the source data 615 and the associated transform metadata 620.The source data 615 and the transformation metadata 620 are supplied to the circuit blocks for the data transformation and compression of the hardware accelerator. The hardware accelerator includes logic (e.g., implemented in hardware and / or firmware) to recognize and read the transform metadata (separate from the data to be compressed) and controls the order in which the source data is processed by the respective transform and compression circuits as directed in the transform metadata. Any transformations of the data are performed prior to forwarding to the compression circuit to compress the transformed source data. The hardware accelerator may write, as an output, the transformed and compressed source data to a target buffer with the (e.g., non-transformed, non-compressed) transformation metadata. In some implementations, the output may be structured to mark the transform metadata as such (e.g., to utilize another system that later accesses and decompresses the data) so that it is not erroneously provided for decompression along with the compressed source data. In an example implementation, the transformation metadata may be provided in the output as a skippable frame (e.g., an LZ4 / ZSTF skippable frame). In the example illustrated by simplified block diagram 700 of FIG. 7, output 705 of a data reduction process performed by the hardware accelerator (e.g., including a series of one or more data transformations followed by compression of the transformed data) may include, in addition to transformation metadata 620 and transformed and compressed data 615', a header 710, such as a skippable frame header. In some implementations, the header 710 (e.g., according to ZSTD / LZ4) may include code (e.g., magic number) that causes the output 705 from a decompressor 425 not to be rejected (e.g., because an expected code is not included in the first portion of the data presented to the decompressor), but that causes a certain number of bits or bytes of the data following the header (corresponding to the transform metadata 620) to be skipped by the decompressor. In an example, the decompressing engine may first analyze the skippable frame 710. In the case of LZ4 / ZSTD frame formats, skippable frames allow insertion of user defined metadata. The skippable frame 710 for the transform metadata 620, in this example, begins with a magic number (e.g., 0x184D2A50) to indicate the presence of the transform metadata. This allows the transform metadata to be handled separately from the compressed data 615' (and parsed by parser 720) provided to decompressor 425 for decompression (before inverse transformations are applied to data 615').While a hardware accelerator may be used for preprocessing to transform and compress the data, it cannot be guaranteed that appropriate hardware (e.g., which may perform both decompressing and retransforming and predicts and understand the transformation metadata) will be used or available by the system that will later access or receive output 705. In some cases, the system to decompress the output may use a software or hardware-based decompressor 425 that is separate from the logic (e.g., 430) used to perform the corresponding inverse transformations on the data 615'. Moreover, the system that processes the output 705 may include a metadata parser 720 (e.g., implemented in hardware, firmware, and / or software) that identifies the transform metadata 620 in the compressed output 705, identifies the series of one or more reversible data transformations applied to the data 615', and causes the inverse transform logic 430 to perform these inverse transformations (e.g., in reverse order) on the data once decompressed by the decompressor 425. In some implementations, the data processing system that accesses the compressed output may be the same system that has performed the compression or another system that includes a hardware accelerator that includes circuitry and / or firmware to implement each of the metadata parser 720, the decompressor 425, and the inverse transforms 430 using hardware. The preprocessing hardware accelerator discussed herein may implement circuitry, among other things, to perform corresponding data transformations / inverse data transformations and compression / decompression, all within the same hardware accelerator IP block or device, among other example implementations. The result of the inverse transform(s) 430 may return the data 615' to its original form (at 725) for further processing, storage in memory, transmission to another device, etc.In block diagram 800 of FIG. 8, a series of one or more data transformations applied by a pre-processing hardware accelerator may be requested. The data transformations are reversed in the reverse order of the data transformations applied to the original data (e.g., 405). For example, in the example of FIG. 8, the original source data 405 is provided to a preprocessing hardware accelerator along with a request to apply a particular series of two data transformations: a delta transformation 410 a, followed by a double delta transformation 410 b. In some implementations, the series of reversible data transformations (e.g., 410 a- b) is performed along with a compression operation (e.g., 805) on the preprocessing hardware accelerator in a single pipeline offload operation. In other cases, the preprocessing hardware accelerator may be used only to perform the data transformations without compression (e.g., if a different (e.g., software-based) compressor is to be used instead of the compression circuit of the preprocessing hardware accelerator). In some implementations, a separate API call may be provided for purely transformation operations of the preprocessing hardware accelerator (e.g., with the compression API call to request transformations within a compression pipeline). Compression and decompression 895 if included in the workflow are to be performed between application of the data transformations (e.g., 410 a- b) to the data and application of the corresponding inverse transformations (e.g., 430 b- a) to the data. Generally, the inverse transformations (e.g., 430 band 430 a) are applied in reverse order than the corresponding transformations (e.g., 410 aand 410 b, respectively).In the example of FIG. 8, the first delta transform 410 aand the second delta transform 410 b(as well as possibly the corresponding inverse transforms 430 a, 430 b) may represent a selected subset of the reversible data transformations implemented in circuits of the preprocessing hardware accelerator. A pre-processing hardware accelerator-defined API may be used to select which of the supported data transformations to apply to given data, and these APIs may be scalable to allow additional, new data transformations to be added for selection by an application (e.g., when the underlying pre-processing hardware accelerator supports the data transformation). In this particular example, delta transform 410 amay support a number of data types and granularities (e.g., type UINT with granularities of 8 b, 16 b, 32 b, 64 b; for type INT, granularities of 8 b, 16 b, 32 b, 64 b; Data, DataTime, DataTime64, among other examples). In the delta transformation, the first data value is not changed, and the subsequent data values are represented as a difference from a previous value. For the delta transformation, a size attribute can also be defined, with which the number of bytes to be stored after the transformation is specified. The second delta transform 410 bmay also support various data types and granularities (e.g., UINT8, UINT16, UINT32, UINT64, etc.), where the transform 410 bresults in a double delta transform through the application of back-to-back delta transforms. For example, the dual data transformation may be useful with monotone data such as time series, data, integer sequences, etc., that gradually change (e.g., sensor data). If compression is to occur subsequent to the data transformations, the data 405 must be transformed at the required granularity (e.g., in the API call) before being sent to the compression circuitry (e.g., a HASH unit) for processing. At the decompressor, this conversion is reversed after the decompressed data is read out from the history buffer and sent to the DRAM.FIG. 9 is a simplified block diagram 900 illustrating the transformation of data (at 905) and the corresponding inverse transformation of the data (at 910) using an example T64 data transformation, which may also be supported in at least some implementations of an enhanced preprocessing hardware accelerator. In this example, the T64 may support a variety of data types and granularities (e.g., type UINT with granularities of 8b, 16b, 32b, 64b; for type INT granularities of 8b, 16b, 32b, 64b; Date, DateTime, DateTime64, among other examples). In a T64 transform, the unused high bits of values may be clipped into integer data types (including Enum, Data, and DataTime). At each transformation step, the hardware acceleration circuit identifies a block of 64 values, places it in a 64xT bit matrix, and transposes it into a transposition matrix. The circuit can then perform a matrix reduction by scanning the transport matrix from top to bottom and removing excess zeros at the head to produce a reduced matrix. The reduced matrix may then be output as a result of the transformation and used as input for another transformation in a row or for the compression circuitry (e.g., to implement an LZ77 compressor) of the preprocessing hardware accelerator for compression. In inverse transform 910, the matrix extension searches for the first null, fills in the remaining data with zeroes, and reverses the order of the data. If there are no zeros or only a leading zero in a 64B block, no padding is performed. The specific data transformations mentioned in this discussion have been provided merely as examples of the potentially numerous other (and future) data transformations that may be implemented in the hardware of a preprocessing accelerator in cooperation with the compression functionality of the preprocessing accelerator, among other examples and considerations.FIG. 10 is a simplified flow diagram 1000 a showing an example technique for performing a data reduction operation that includes both data transformations and compression in a hardware accelerator as a single offload operation. For example, a request to perform data reduction may be received at the hardware accelerator (e.g., via an API). The request may identify one or more reversible data transformations from a set of data transformations supported by the hardware accelerator and to be applied to particular data (e.g., in a source buffer). If more than one data transform is to be applied to the data, the order in which the identified data transforms are to be applied (e.g., the granularity to be applied, the size of the transform output, etc.) may also be specified in the request, among other examples. The identified data transformations are applied 1010 to the data using hardware circuitry of the hardware accelerator to generate a transformed version of the data. The transformed version of the data may then be compressed with lossless compression performed by circuitry of the hardware accelerator to generate compressed transformed data based on the request. The hardware accelerator generates an output including the compressed transformed data along with transform metadata, the transform metadata describing the one or more reversible data transformations applied to the transform metadata. The output may then be sent to a destination (e.g., to a destination buffer, system memory, another device over a system bus, another device over a network, etc.).Also illustrated is a decompression technique 1000 b, which may follow the example compression technique 1000 a. The compressed data output may be accessed, for example, from another device or the same hardware accelerator (1030). The transform metadata present in the output may be identified 1035 (e.g., using a skip header also present in the output) and parsed 1040 to identify the one or more reversible data transformations applied to the compressed transformed data present in the output. The compressed transformed data may be selected (without the transform metadata) and 1045 decompressed to generate decompressed transformed data. The information from the transform metadata may then be used to apply 1050 one or more corresponding inverse transformations to the decompressed transformed data (in a reverse order than the transformation of the original data) to restore the data 1055 to its original form (e.g., for further processing by the system accessing the data 1030, among other example functions).Note that the above-described devices, methods, and systems may be implemented in any electronic device or system, as mentioned above. In particular, a pre-processing hardware accelerator as described herein may be coupled to or incorporated into a variety of different electronic devices or systems to offload certain pre-processing tasks, including data reduction operations, from other processing hardware (e.g., a CPU) of the system. For purposes of illustration, FIG. 11 shows an example implementation of a processing device that may include, or be coupled to, and use (e.g., to offload workloads), e.g., a preprocessing hardware accelerator. It should be appreciated that other processor architectures may also be available to implement the functionality and processing of requests by an example network processing device, including the implementation of the above-described components and functions of the example network processing device. While the above examples focus on improvements to an Ethernet subsystem and connections compatible with an Ethernet-based protocol, it is important to note that the principles discussed herein are protocol independent and can be applied to connections based on a variety of other technologies, such as PCIe, CXL, UCl, CCIX, Infinity Fabric, and other examples.Turning now to FIG. 11, a block diagram 1100 of an example computing device (e.g., a central processing unit (CPU)) 1112 is shown coupled to various other components of a platform, in accordance with certain embodiments. Although the figure of the CPU 1112 illustrates a particular configuration, the cores and other components of the CPU 1112 may be arranged in any suitable manner. The CPU 1112 may include any processor or processing device, such as a microprocessor, an embedded processor, a digital signal processor (DSP), a network processor, an application processor, a coprocessor, a system on a chip (SOC), or other device for executing code. The CPU 1112 in the illustrated embodiment includes four processing elements (cores 1102 in the illustrated embodiment) that may include asymmetric processing elements or symmetric processing elements. However, the CPU 1112 may include any number of processing elements that may be symmetric or asymmetric.In one embodiment, a processing element refers to hardware or logic for supporting a software thread. Examples of hardware processing elements include: a thread unit, a thread slot, a thread, a process unit, a context, a context unit, a logical processor, a hardware thread, a core, and / or any other element capable of maintaining a state for a processor, such as an execution state or architectural state. In other words, in one embodiment, a processing element refers to any hardware capable of independently communicating with code, such as a software thread, operating system, application, or other code. A physical processor (or processor socket) typically refers to an integrated circuit that potentially includes any number of other processing elements, such as cores or hardware threads.A core may refer to logic disposed on an integrated circuit capable of maintaining an independent architectural state, each independently maintained architectural state associated with at least some dedicated execution resources. A hardware thread may refer to any logic disposed on an integrated circuit capable of maintaining an independent architectural state, wherein the independently maintained architectural states share access to execution resources. As can be seen, the line between the nomenclature of a hardware thread and a kernel overlaps when certain resources are shared and others are dedicated to an architectural state. However, often a core and a hardware thread are considered individual logical processors by an operating system, where the operating system is capable of individually scheduling operations on each logical processor.Physical CPU 1112, as shown in FIG. 11, includes four cores: 1102A, 1102B, 1102C, and 1102D, although a CPU may include any suitable number of cores. Here, the cores 1102 may be considered as symmetric cores. In other embodiments, cores may include one or more out-of-order processor cores or one or more out-of-order processor cores. However, cores 1102 may be individually selected from any type of core, such as a native core, a software managed core, a core configured to execute a native instruction set architecture (ISA), a core configured to execute a translated ISA, a co-designed core, or any other known core. In a heterogeneous core environment (e.g., asymmetric cores), some form of translation, such as binary translation, may be used to plan or execute code on one or both cores.A core 1102 may include a decode module coupled to a fetch unit to decode fetched elements. In one embodiment, fetch logic includes individual sequencers that are each connected to thread slots of cores 1102. Typically, core 1102 is coupled to a first ISA that defines / specifies instructions executable on core 1102. Often, machine code instructions that are part of the first ISA include a portion of the instruction (referred to as opcode) that references / specifies an instruction or operation to be executed. The decode module may include circuitry that recognizes these instructions from their opcodes and forwards the decoded instructions in the pipeline for processing as defined by the first ISA. For example, in one embodiment, decoders may include logic designed or adapted to recognize particular instructions, such as transaction instructions. As a result of the detection by the decoders, the architecture of the core 1102 performs specific, predefined actions to perform the tasks associated with the corresponding instruction. It is important to note that each of the tasks, blocks, operations, and methods described herein may be performed in response to a single or multiple instructions; some of these may be new or old instructions. In one embodiment, the decoders of cores 1102 recognize the same ISA (or subset thereof). Alternatively, in a heterogeneous core environment, a decoder of one or more cores (e.g., core 1102B) may recognize a second ISA (either a subset of the first ISA or a different ISA).In various embodiments, cores 1102 may also include one or more arithmetic logic units (ALUs), floating point units (FPUs), caches, instruction pipelines, interrupt handling hardware, registers, or other suitable hardware to facilitate operation of cores 1102.Bus 1108 may represent any connection coupled to CPU 1112. In one example, bus 1108 may connect CPU 1112 to another CPU of platform logic (e.g., via UPI). I / O blocks 1104 represent interface logic to couple I / O devices 1110 and 1115 to cores of CPU 1112. In various embodiments, an I / O block 1104 may include an I / O controller integrated into the same package as the cores 1102, or may simply include interface logic for coupling to an off-chip I / O controller. As an example, the I / O blocks 1104 may include PCIe interface logic. Similarly, memory controller 1106 represents interface logic to connect memory 1114 to the cores of CPU 1112. In various embodiments, the memory controller 1106 is integrated on the same package as the cores 1102. In alternative embodiments, a memory controller could be packaged off-chip.As various examples, in the illustrated embodiment, core 1102A may have a relatively high bandwidth and lower latency to the devices coupled to bus 1108 (e.g., other CPUs 1112) and NICs 1110, but a relatively low bandwidth and higher latency to memory 1114 or core 1102D. Core 1102B may have relatively high bandwidths and low latencies for both NICs 1110 and PCIe solid state drives (SSDs) 1115, and moderate bandwidths and latencies for devices connected to bus 1108 and core 1102D. Core 1102C would have relatively high bandwidths and low latencies to memory 1114 and core 1102D. Finally, 1102D would have relatively high bandwidth and low latency to core 1102C, but relatively low bandwidths and high latencies to NICs 1110, core 1102A, and devices coupled to bus 1108."Logic" (e.g., in I / O controllers, power managers, latency managers, etc., and other references to logic in this application) may refer to hardware, firmware, software, and / or combinations thereof for performing one or more functions. In various embodiments, the logic may include a microprocessor or other processing element for executing software instructions, discrete logic such as an application specific integrated circuit (ASIC), a programmed logic device such as a field programmable gate array (FPGA), a memory device containing instructions, combinations of logic devices (e.g., as found on a printed circuit board), or other suitable hardware and / or software. The logic may include one or more gates or other circuit components. In some embodiments, the logic may also be embodied entirely as software.A design may go through several stages, from generation to simulation to fabrication. Data representing a design may represent the design in multiple ways. First, which is useful in simulations, the hardware may be represented using a hardware description language (HDL) or other functional description language. Additionally, in some stages of the design process, a circuit level model with logic and / or transistor gates may be produced. Moreover, most designs eventually reach a level of data representing the physical placement of various devices in the hardware model. In the case where conventional semiconductor fabrication techniques are used, the data representing the hardware model may be the data indicating the presence or absence of various features on different mask layers for masks used to produce the integrated circuit. In some implementations, such data may be stored in a database file format such as Graphic Data System II (GDS II), Open Artwork System Interchange Standard (OASIS), or similar format.In some implementations, software-based hardware models, as well as HDL and other functional description language objects, may include, but are not limited to, register transfer language (RTL) files. Such objects may be machine-cut so that a design tool may accept the HDL object (or model), analyze the HDL object for attributes of the described hardware, and determine a physical circuit and / or an on-chip layout from the object. The results of the design tool may be used to fabricate the physical device. For example, a design tool may determine configurations of various hardware and / or firmware elements from the HDL object, such as bus widths, registers (including sizes and types), memory blocks, physical connection paths, fabric topologies, and other attributes implemented to implement the system modeled in the HDL object. Design tools may include tools for determining system on chip (SoC) topology and fabric configurations and other hardware devices. In some cases, the HDL object may be used as a basis for the development of models and design files that may be used by manufacturing facilities to fabricate the described hardware. Indeed, an HDL object itself may be provided as input to the manufacturing system software to generate the described hardware.In any representation of the design, the data may be stored in any form of machine readable medium. A storage element or magnetic or optical data carrier, such as a disc, may be the machine readable medium for storing information transmitted over optical or electrical waves that are modulated or otherwise generated to transmit such information. When an electric carrier wave indicating or carrying the code or design is transmitted to the extent that copying, buffering, or retransmission of the electric signal is performed, a new copy is made. Thus, a communication provider or network operator may, at least temporarily, store on a tangible, machine-readable medium an article, such as information encoded in a carrier wave, embodying techniques of embodiments of the present disclosure.A module as used herein refers to any combination of hardware, software, and / or firmware. As an example, a module includes hardware, such as a microcontroller, coupled to a non-volatile storage medium to store code adapted to be executed by the microcontroller. Thus, reference to a module in one embodiment refers to the hardware specifically configured to recognize and / or execute code to be maintained on a non-volatile storage medium. Moreover, in another embodiment, use of a module refers to the non-volatile medium containing the code specifically adapted to be executed by the microcontroller to perform predetermined operations. And as can be seen, in yet another embodiment, the term module (in this example) may refer to the combination of the microcontroller and the non-volatile data carrier. Often, module boundaries shown as separate may generally vary and potentially overlap. For example, first and second modules may share hardware, software, firmware, or a combination thereof, while potentially maintaining independent portions of hardware, software, or firmware. In one embodiment, the use of the term logic includes hardware, such as transistors, registers, or other hardware, such as programmable logic devices.The use of the phrase "to" or "configured to" in one embodiment refers to arranging, assembling, manufacturing, offering for sale, importing, and / or designing a device, hardware, logic, or element for performing a specified or particular task. In this example, an apparatus or element thereof that / is not functioning is still "configured to" perform a specified task when designed, coupled, and / or connected to perform the specified task. As a purely illustrative example, a logic gate may provide a 0 or a 1 during operation. However, a logic gate "configured to" provide an enable signal to a clock does not include any potential logic gate that may provide a 1 or 0. Instead, the logic gate is one which is coupled in a manner such that the output of 1 or 0 during operation serves to enable the clock. It should be noted once again that the use of the term "configured to" does not require an operation, but instead focuses on the latent state of a device, hardware, and / or element where, in the latent state, the device, hardware, and / or element is designed to perform a particular task when the device, hardware, and / or element is operating.Moreover, in one embodiment, use of the terms "capable of / to" and / or "operable to" refers to a device, logic, hardware, and / or element designed in a manner to enable use of the device, logic, hardware, and / or element in a particular manner. Note as above that the use of "to", "capable of", or "operable to" in one embodiment refers to the latent state of a device, logic, hardware, and / or element in which the device, logic, hardware, and / or element is not operational, but is designed in a manner to enable use of a device in a particular manner.A value as used herein includes any known representation of a number, state, logical state, or binary logical state. Often, the use of logic levels, logic values or logic values is also referred to as ones and zeros, which simply represents binary logic states. For example, a 1 refers to a high logic level and 0 refers to a low logic level. In one embodiment, a memory cell, such as a transistor or flash cell, may be capable of holding a single logical value or multiple logical values. However, other representations of values have been used in computer systems. For example, decimal number ten may be represented as binary value 418A0and hexadecimal letter A. Thus, a value includes any representation of information that can be stored in a computer system.Moreover, states may be represented by values and parts of values. As an example, a first value, such as a logical one, may represent a default or initial state, while a second value, such as a logical zero, may represent a non-default state. Moreover, in one embodiment, the terms reset and set each to a default and an updated value or state. For example, a default value potentially includes a high logical value, i.e., reset, while an updated value potentially includes a low logical value, i.e., set. Note that any combination of values may be used to represent any number of states.The embodiments of methods, hardware, software, firmware, or code set forth above may be implemented via instructions or code stored on a machine-accessible, machine-readable, computer-accessible, or computer-readable medium and executable by a processing element. A non-transitory machine-accessible / readable medium includes any mechanism that provides (i.e., stores and / or transmits) information in a form readable by a machine, such as a computer or electronic system. For example, a non-transitory machine-accessible medium includes random access memory (RAM) such as static RAM (SRAM) or dynamic RAM (DRAM), ROM, a magnetic or optical storage medium, flash memory devices, electrical storage devices, optical storage devices, acoustical storage devices, other forms of storage devices for holding information received from transitory (propagated) signals (e.g., carrier waves, infrared signals, digital signals), etc., to be distinguished from the non-transitory media that can receive information therefrom.Instructions used to program logic to perform embodiments of the disclosure may be stored within a memory in the system, such as DRAM, cache, flash memory, or other storage element. Moreover, the instructions may be distributed over a network or via other computer readable media. Thus, a machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer), but is not limited to floppy diskettes, optical disks, compact disks, read-only memories (CD-ROMs), and magneto-optical disks, read-only memories (ROMs), random access memories (RAMs), erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), magnetic or optical cards, flash memories, or a tangible, machine-readable storage that is used in the transmission of information over the Internet through electrical, optical, acoustical or other forms of propagated signals (e.g., carrier waves, infrared signals, Digital signals, etc.) are used. Accordingly, the computer-readable medium includes any type of tangible, machine-readable medium suitable for storing or transmitting electronic instructions or information in a form readable by a machine (e.g., a computer).The following examples are directed to embodiments consistent with this specification. Example 1 is an apparatus comprising: a hardware accelerator comprising: one or more interfaces to receive a request to perform one or more data reduction operations on data; a transformation circuit to apply a set of reversible data transformations to the data based on the request to generate transformed data; and a compression circuit to compress the transformed data to generate compressed transformed data; and an output circuit to generate an output of the one or more data reduction operations, wherein the output comprises the compressed transformed data and transformation metadata, and the transformation metadata indicates the set of reversible data transformations applied to the compressed transformed data.Example 2 includes the subject matter of Example 1, and wherein the data is read from system memory and the output is written to system memory to correspond to the request in a single offload operation.Example 3 includes the subject matter of any of Examples 1-2, and wherein the request is received from an application via an application programming interface (API) defined for the hardware accelerator.Example 4 includes the subject matter of any of Examples 1-3, wherein the set of reversible data transformations comprises a plurality of reversible data transformations to be applied in a particular order based on the request to generate the transformed data.Example 5 includes the subject matter of Example 4, wherein the transformation metadata identifies the respective sequence.Example 6 includes the subject matter of any of Examples 1-5, wherein the output further includes header data to indicate the presence of the transform metadata and prevent the transform metadata from being decompressed by a decompressor in a subsequent operation.Example 7 includes the subject matter of Example 6, wherein the header data includes code indicating that the output includes the transformation metadata to be skipped by the decompressor during the decompression.Example 8 includes the subject matter of any of Examples 1-7, wherein the output is to be sent to another device over a connection.Example 9 includes the subject matter of any of Examples 1-8, wherein the data is compressed according to a lossless compression algorithm.Example 10 includes the subject matter of any of Examples 1-9, and wherein the request includes a listing of the set of reversible data transformations to apply to the data.Example 11 includes the subject matter of Example 10, wherein the listing indicates a corresponding granularity for each set of reversible data transformations.Example 12 includes the subject matter of any of Examples 1-11, further comprising: parsing logic to: identify transform metadata of other compressed data; and determine a sequence of transforms applied to the other compressed data based on the transform metadata for the other compressed data; decompressing circuitry to decompress the other compressed data to generate decompressed transformed data; and reverse transforming circuitry to apply the transforms in the sequence of transforms to the decompressed transformed data in a reverse order from the sequence of transforms identified in the transform metadata of the other compressed data.Example 13 includes the subject matter of any of Examples 1-12, wherein the set of reversible data transformations comprises at least one of a delta transformation, a double delta transformation, a T64 transformation, a Burrows-Wheeler transformation, or an XOR transformation.Example 14 includes the subject matter of any of Examples 1-13, wherein the preprocessing accelerator further includes a cryptographic circuit to encrypt or decrypt data.Example 15 is a method comprising: receiving a request at a hardware accelerator in a system to perform one or more data reduction operations on data; applying one or more reversible data transformations to the data using hardware circuits of the hardware accelerator based on the request to generate transformed data; compressing the transformed data using hardware circuits of the hardware accelerator to generate compressed transformed data; and generating an output of the one or more data reduction operations, wherein the output includes the compressed transformed data and transformation metadata, and the transformation metadata indicates the one or more reversible data transformations applied to the compressed transformed data.Example 16 includes the subject matter of Example 15, further including: accessing the output; parsing the transform metadata to identify the one or more reversible data transforms; decompressing the compressed transformed data to generate decompressed transformed data; and applying inverse transforms corresponding to the set of reversible data transforms to the decompressed transformed data to restore the data.Example 17 includes the subject matter of any of Examples 15-16, and wherein the request includes a request to offload the transformation and compression of the data from a central processing unit (CPU) to the hardware accelerator in a single offload operation.Example 18 includes the subject matter of any of Examples 15-17, and wherein the request is received from an application via an application programming interface (API) defined for the hardware accelerator.Example 19 includes the subject matter of any of Examples 15-18, and wherein the set of reversible data transformations comprises a plurality of reversible data transformations to be applied in a particular order based on the request to generate the transformed data.Example 20 includes the subject matter of Example 19, wherein the transformation metadata identifies the respective sequence.Example 21 includes the subject matter of any of Examples 15-20, and wherein the output further includes header data to indicate the presence of the transform metadata and prevent the transform metadata from being decompressed by a decompressor in a subsequent operation.Example 22 includes the subject matter of Example 21, wherein the header data includes code indicating that the output includes the transformation metadata to be skipped by the decompressor during the decompression.Example 23 includes the subject matter of any of Examples 15-22, and wherein the output is sent to another device via an interconnect.Example 24 includes the subject matter of any of Examples 15-23, and wherein the data is compressed according to a lossless compression algorithm.Example 25 includes the subject matter of any of Examples 15-24, and wherein the request includes a listing of the set of reversible data transformations to apply to the data.Example 26 includes the subject matter of Example 25, wherein the listing indicates a corresponding granularity for each set of reversible data transformations.Example 27 includes the subject matter of any of Examples 15-26, and wherein the set of reversible data transformations includes at least one of a delta transformation, a double delta transformation, a T64 transformation, a Burrows-Wheeler transformation, or an XOR transformation.Example 28 includes the subject matter of any of Examples 15-27, and wherein the data is encrypted using hardware circuitry of the hardware accelerator.Example 29 is a system comprising means for performing the method of any of Examples 15-28.Example 30 includes the subject matter of Example 29, wherein the means comprises a non-transitory machine-readable storage medium having instructions stored thereon, the instructions executable to cause a machine to perform at least part of the method of any of Examples 15-28.Example 31 is a system comprising: a processor device; a memory; a hardware accelerator coupled to the processor device and the memory, the hardware accelerator comprising circuitry to: receive a request to perform data reduction on particular data in the memory, the request identifying a set of reversible data transformations to apply to the particular data prior to compressing the particular data; apply the set of reversible data transformations to the data to generate transformed data; compress the transformed data to generate compressed transformed data; and generate an output including the compressed transformed data and transformation metadata, the transformation metadata indicating the set of reversible data transformations applied to the compressed transformed data.Example 32 includes the subject matter of Example 31, further comprising an apparatus for: accessing the output; analyzing the transform metadata to identify the set of reversible data transforms applied to the compressed transformed data; decompressing the compressed transformed data to generate decompressed transformed data; and applying a set of reverse transforms to the decompressed transformed data to restore the determined data.Example 33 includes the subject matter of any of Examples 31-32, and wherein the determined data includes one of a plurality of segments of a dataset, and the hardware accelerator is to apply the set of reversible data transformations and compress each of the plurality of segments of the dataset for an application executed by the processor device.Example 34 includes the subject matter of any of Examples 31-33, wherein the request is received from an application via an application programming interface (API) defined for the hardware accelerator.Example 35 includes the subject matter of any of Examples 31-34, and wherein the set of reversible data transformations comprises a plurality of reversible data transformations to be applied in a particular order based on the request to generate the transformed data.Example 36 includes the subject matter of Example 35, wherein the transformation metadata identifies the respective sequence.Example 37 includes the subject matter of any of Examples 31-36, and wherein the output further includes header data to indicate the presence of the transform metadata and prevent the transform metadata from being decompressed by a decompressor in a subsequent operation.Example 38 includes the subject matter of Example 37, wherein the header data includes code indicating that the output includes the transformation metadata to be skipped by the decompressor during the decompression.Example 39 includes the subject matter of any of Examples 31-38, and wherein the output is to be sent to another device over a connection.Example 40 includes the subject matter of any of Examples 31-39, and wherein the data is compressed according to a lossless compression algorithm.Example 41 includes the subject matter of any of Examples 31-40, and wherein the request includes a listing of the set of reversible data transformations to apply to the data.Example 42 includes the subject matter of Example 41, wherein the listing indicates a corresponding granularity for each set of reversible data transformations.Example 43 includes the subject matter of any of Examples 31-42, and wherein the set of reversible data transformations includes at least one of a delta transformation, a double delta transformation, a T64 transformation, a Burrows-Wheeler transformation, or an XOR transformation.Example 44 includes the subject matter of any of Examples 31-43, and wherein the data is encrypted using hardware circuitry of the hardware accelerator.Example 45 includes the subject matter of any of Examples 31-44, and wherein the request includes a request to offload the transformation and compression of the data from the processor unit to the hardware accelerator in a single offload operation.Example 46 includes the subject matter of any of Examples 31-45, and wherein the system includes a personal computer.Example 47 includes the subject matter of any of Examples 31-45, and wherein the system includes a server platform.Example 48 includes the subject matter of any of Examples 31-45, and wherein the system includes a smartphone.Throughout this specification, reference to "a single embodiment" or "an embodiment" means that certain features, structures, or characteristics described in connection with the embodiment are included in at least one embodiment of the present disclosure. Thus, the appearances of the phrases "in a single embodiment" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Moreover, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.In the foregoing specification, a detailed description has been given with reference to specific exemplary embodiments. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the disclosure as set forth in the appended claims. The specifications and drawings are accordingly to be considered in an illustrative sense rather than a restrictive sense. Moreover, the foregoing use of the embodiment and other example language does not necessarily refer to the same embodiment or example, but may refer to different and separate embodiments, as well as potentially the same embodiment.

Claims

An apparatus comprising: a hardware accelerator comprising: one or more interfaces to receive a request to perform one or more data reduction operations on data; a transformation circuit to apply a set of reversible data transformations to the data based on the request to generate transformed data; and compression circuits to compress the transformed data to generate compressed transformed data; and output circuits to generate an output of the one or more data reduction operations, wherein the output comprises the compressed transformed data and transformation metadata, and the transformation metadata indicates the set of reversible data transformations applied to the compressed transformed data.The apparatus of claim 1, wherein the data is read from system memory and the output is written to system memory to correspond to the request in a single offload operation.The apparatus of any of claims 1-2, wherein the request is received from an application via an application programming interface (API) defined for the hardware accelerator.The apparatus of any of claims 1 to 3, wherein the set of reversible data transformations comprises a plurality of reversible data transformations to be applied in a particular order based on the request to generate the transformed data.The apparatus of claim 4, wherein the transformation metadata identifies the particular sequence.The apparatus of any of claims 1 to 5, wherein the output further comprises header data to indicate the presence of the transform metadata and prevent the transform metadata from being decompressed by a decompressor in a subsequent operation.The apparatus of claim 6, wherein the header data comprises code indicating that the output comprises the transform metadata to be skipped by the decompressor during decompression.The apparatus of any one of claims 1 to 7, wherein the output is to be sent to another device via an interconnect.The apparatus of any of claims 1-8, wherein the data is compressed according to a lossless compression algorithm.The apparatus of any of claims 1-9, wherein the request comprises a listing of the set of reversible data transformations to be applied to the data.The apparatus of claim 10, wherein the listing indicates a corresponding granularity for each of the set of reversible data transformations.The apparatus of any of claims 1-11, further comprising: parsing logic to: identify transform metadata of other compressed data; and determine a sequence of transforms applied to the other compressed data based on the transform metadata for the other compressed data; decompressing circuitry to decompress the other compressed data to generate decompressed transformed data; and inverse transforming circuitry to apply the transforms in the transform sequence to the decompressed transformed data in reverse order from the transform sequence identified in the transform metadata of the other compressed data.The apparatus of any of claims 1-12, wherein the set of reversible data transformations comprises at least one of a delta transformation, a double delta transformation, a T64 transformation, a floating point transformation, or an XOR transformation.The apparatus of any of claims 1 to 13, wherein the preprocessing accelerator further comprises a cryptographic circuit to perform either encryption or decryption of data.A method comprising: receiving, at a hardware accelerator in a system, a request to perform one or more data reduction operations on data; applying one or more reversible data transformations to the data using hardware circuits of the hardware accelerator, based on the request, to generate transformed data; and compressing the transformed data using hardware circuits of the hardware accelerator to generate compressed transformed data; and generating an output of the one or more data reduction operations, wherein the output comprises the compressed transformed data and transformation metadata, and the transformation metadata indicates the one or more reversible data transformations applied to the compressed transformed data.The method of claim 15, further comprising: accessing the output; analyzing the transform metadata to identify the one or more reversible data transformations; decompressing the compressed transformed data to generate decompressed transformed data; and applying inverse transformations corresponding to the set of reversible data transformations to the decompressed transformed data to restore the data.The method of any of claims 15-16, wherein the request comprises a request to offload the transformation and compression of the data from a central processing unit (CPU) to the hardware accelerator in a single offload operation.System comprising means for carrying out the method according to one of Claims 15 - 17.A system comprising: a processor device; a memory; a hardware accelerator coupled to the processor device and the memory, the hardware accelerator comprising circuitry for: receiving a request to perform data reduction on particular data in the memory, the request indicating a set of reversible data transformations to be applied to the particular data prior to compressing the particular data; applying the set of reversible data transformations to the data to generate transformed data; and compressing the transformed data to generate compressed transformed data; and generating an output comprising the compressed transformed data and transformation metadata, the transformation metadata indicating the set of reversible data transformations applied to the compressed transformed data.The system of claim 19, further comprising an apparatus for: accessing the output; analyzing the transform metadata to determine the set of reversible data transformations applied to the compressed transformed data; decompressing the compressed transformed data to generate decompressed transformed data; and applying a set of inverse transformations to the decompressed transformed data to restore the determined data.The system of any of claims 19 to 20, wherein the determined data comprises one of a plurality of segments of a dataset and the hardware accelerator is to apply the set of reversible data transformations and compress each of the plurality of segments of the dataset for an application executed by the processor device.The system of any of claims 19-21, wherein the set of reversible data transformations comprises a plurality of reversible data transformations to be applied in a particular order based on the request to generate the transformed data.The system of claim 22, wherein the transformation metadata identifies the particular sequence.The system of any of claims 19-23, wherein the output further comprises header data to indicate the presence of the transform metadata and prevent the transform metadata from being decompressed by a decompressor in a subsequent operation.The system of any of claims 19-24, wherein the system comprises a server platform or a personal computer.

Images