Method and system for acceleration or offloading with unified data pointers

Abstract

Embodiments of the present disclosure relate to methods and systems for accelerating or offloading with a unified data pointer. Methods, systems, and devices for performing an acceleration process through an offload operation. In one embodiment, a system includes a hardware offload engine including a hardware accelerator for performing an acceleration process. The hardware accelerator has a processor configured to receive a hardware offload command including an opcode, an input pointer, and an output pointer, where at least one of the input pointer or the output pointer includes a unified data pointer, the unified data pointer including one or more memory bits, the one or more memory bits are used to identify a source location of the input data or a destination location of the output data, parse the opcode, the input pointer, and the output pointer from the hardware offload command, retrieve the input data based on the input pointer, and perform an offload operation on the input data based on the opcode.

Description

Technical Field

[0001] Embodiments described herein generally relate to non-volatile storage systems. More specifically, embodiments described herein relate to methods and systems for accelerating or offloading operations of non-volatile storage systems (e.g., cloud computing services), wherein an offload command for a hardware offload operation includes a unified data pointer. Background Art

[0002] Non-volatile storage (e.g., block-level storage) is a common form of storage that is used to store data in a storage area network (e.g., server), cloud-based storage environments, data centers, and the like. Cloud-based storage or storage devices are common products provided by cloud service providers (CSPs). In cloud-based storage or storage devices, data acceleration can be used by offloading operations from a host controller to non-volatile storage system hardware, for example, to a controller having hardware, software, and / or firmware that communicates with a non-volatile storage device, for example, on a server or connected via a peripheral component interconnect express (PCIe) card. Summary of the invention

[0003] Methods, systems, and devices are described herein for optimizing a non-volatile storage system using hardware offload or hardware acceleration by utilizing a unified data pointer in an offload command for hardware acceleration and / or hardware offload operations, for example, in a heterogeneous storage device and storage device system having at least two types of data locations. The unified data pointer can be used to point to (multiple) specific memory locations where data is to be sourced from (e.g., read) or data needs to be stored (e.g., written) thereto. That is, the method, system, and device are designed, programmed, or otherwise configured to prepare and / or parse an offload command that includes a data field for identifying a source of input data and / or a destination of output data using a unified data pointer so that a single command can be used to represent all types of different data transfers / directions, for example, different storage / memory locations for reading / writing data, such as Table 1 and / or various devices from a heterogeneous storage device and storage device system.

[0004] In an embodiment, a hardware offload engine for performing an acceleration process is provided. The hardware offload engine includes a hardware accelerator for performing an acceleration process, and the hardware accelerator has a processor configured to receive a hardware offload command. The hardware offload command includes an opcode, an input pointer for identifying a source location of input data for the hardware accelerator, and an output pointer for identifying a destination location of output data from the hardware accelerator, wherein at least one of the input pointer or the output pointer includes a unified data pointer, and the unified data pointer includes one or more memory bits, and the one or more memory bits are used to identify the source location of the input data or the destination location of the output data. The hardware accelerator is also configured to parse the opcode, the input pointer, and the output pointer from the hardware offload command, retrieve the input data based on the input pointer, and perform an offload operation on the input data based on the opcode.

[0005] In another embodiment, a nonvolatile storage device is provided. The nonvolatile storage device includes a nonvolatile storage device and a controller. The controller includes a hardware offload engine for performing an acceleration process. The hardware offload engine includes a first interface for communicating with a host device; a second interface for communicating with the nonvolatile storage device; and a hardware accelerator for performing an acceleration process. The hardware accelerator has a processor configured to receive a hardware offload command from the host device from the interface, the hardware offload command including an opcode, an input pointer for identifying a source location of input data of the hardware accelerator, and an output pointer for identifying a destination location of output data from the hardware accelerator, wherein at least one of the input pointer or the output pointer includes a unified data pointer, the unified data pointer includes one or more memory bits, the one or more memory bits are used to identify the source location of the input data or the destination location of the output data, parse the opcode, input pointer, input data size, output pointer and output data size from the hardware offload command, retrieve the input data based on the input pointer and the input data size, and perform an offload operation on the input data based on the opcode.

[0006] In another embodiment, a hardware offload engine for performing an acceleration process is provided. The hardware offload engine includes a hardware accelerator for performing the acceleration process, the hardware accelerator having a processor, the processor being configured to receive a hardware offload command, the hardware offload command including an opcode, an input pointer for identifying a source location of input data, and an output pointer for identifying a destination location of output data, wherein at least one of the input pointer or the output pointer includes a unified data pointer, the unified data pointer includes one or more memory bits, the one or more memory bits are used to identify a source location for the input data or a destination location for the output data, and an operation of performing an offload on the input data based on the opcode.

[0007] In another embodiment, a method for performing an acceleration process by offloading an operation to a hardware offload engine is provided. The method includes receiving a hardware offload command, the hardware offload command including an opcode, an input pointer for identifying a source location of input data, and an output pointer for identifying a destination location of output data, wherein at least one of the input pointer or the output pointer includes a unified data pointer, the unified data pointer including one or more memory bits, the one or more memory bits being used to identify a source location for the input data or a destination location for the output data; parsing the opcode, the input pointer, and the output pointer from the hardware offload command; retrieving the input data based on the input pointer; and performing an offload operation on the input data on the hardware offload engine based on the opcode.

[0008] In an embodiment, a host device configured to communicate with a non-volatile storage device is provided. The host device includes a non-transitory computer-readable medium having computer-executable instructions stored thereon, which when executed cause one or more processors to perform operations including: preparing a hardware offload command by providing an opcode, an input pointer for identifying a source location of input data of a hardware accelerator, and an output pointer for identifying a destination location of output data from the hardware accelerator, wherein at least one of the input pointer or the output pointer includes a unified data pointer including one or more memory bits for identifying a source location for the input data or a destination location for the output data, sending the hardware offload command, and receiving a completion command.

[0009] In another embodiment, a non-transitory computer-readable medium is provided, on which computer-executable instructions are stored. The non-transitory computer-readable medium has computer-executable instructions, which when executed cause one or more processors to perform operations including: receiving a hardware offload command, the hardware offload command including an opcode, an input pointer for identifying a source location of input data, and an output pointer for identifying a destination location of output data, wherein at least one of the input pointer or the output pointer includes a unified data pointer, the unified data pointer including one or more memory bits, the one or more memory bits for identifying a source location for the input data or a destination location for the output data, parsing the opcode, the input pointer, and the output pointer from the hardware offload command, retrieving the input data based on the input pointer, and performing an offload operation on the input data on a hardware offload engine based on the opcode.

[0010] Thus, in the embodiments disclosed herein, the performance of the non-volatile storage system can be optimized by using a unified indexing mechanism to identify one or more different data directions, thereby minimizing the number of commands required to access various memories or storage locations to read and / or write data from one or more different data directions (e.g., locations). Thus, in an embodiment, by using an opcode including a unified indexing mechanism (e.g., a unified data pointer), any data transfer, such as from a host-side memory, a device-side memory, and / or a device-side storage block, can be described without introducing new commands (e.g., data for offloaded hardware acceleration operations). BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The accompanying drawings illustrate various embodiments of systems, methods, and embodiments of other various aspects of the present disclosure. It will be appreciated by those skilled in the art that the element boundaries (e.g., boxes, frame groups, or other shapes) illustrated in the figures represent an example of boundaries. In some examples, an element may be designed as multiple elements, or multiple elements may be designed as one element. In some examples, an element shown as an internal component of an element may be implemented as an external component in another element, and vice versa. Non-restrictive and non-exhaustive descriptions are described with reference to the following drawings. The components in the figures are not necessarily drawn to scale, but are focused on the explanation principle. In the following detailed description, the embodiments are described only as illustrations, because those skilled in the art can clearly see various changes and modifications from the following detailed description.

[0012] Figure 1 is a schematic diagram of an example cloud-based storage system arranged in accordance with at least some embodiments described herein.

[0013] Figure 2 is a schematic diagram of example worker nodes in a data center arranged in accordance with at least some embodiments described herein.

[0014] Figure 3A , Figure 3B , Figure 3C , Figure 3D is a representation of an example uninstall command arranged in accordance with at least some embodiments described herein.

[0015] Figure 4 is a schematic diagram of example uninstall commands in an example worker node in a data center arranged according to at least some embodiments described herein.

[0016] Figure 5 is a flow diagram of an example uninstall operation arranged in accordance with at least some embodiments described herein.

[0017] Figure 6is a schematic block diagram of an example computer system that may be suitable for implementing an apparatus, arranged in accordance with at least some embodiments described herein. DETAILED DESCRIPTION

[0018] In the following detailed description, specific embodiments of the present disclosure are described herein with reference to the accompanying drawings, which form a part of the description. In this description and in the drawings, unless the context otherwise dictates, the same reference numerals represent elements that can perform the same, similar, or equivalent functions. In addition, unless otherwise specified, the description of each consecutive figure may refer to features from one or more previous figures to provide a clearer context and a more substantial explanation of the current example embodiment. However, the example embodiments described in the detailed description, the drawings, and the claims are not intended to be limiting. Other embodiments may be utilized, and other changes may be made without departing from the spirit or scope of the subject matter presented herein. It is readily understood that, as generally described herein and illustrated in the drawings, the various aspects of the present disclosure may be arranged, replaced, combined, separated, and designed in a variety of different configurations, all of which are expressly contemplated herein.

[0019] It should be understood that the disclosed embodiments are merely examples of the present disclosure, which may be embodied in various forms. Well-known functions or structures are not described in detail to avoid obscuring the present disclosure with unnecessary details. Therefore, the specific structural and functional details disclosed herein should not be interpreted as limiting, but should only serve as a basis for the claims and as a representative basis for teaching those skilled in the art to variously adopt the present disclosure with almost any appropriate detailed structure.

[0020] In addition, the disclosure may be described in the form of functional block components and various processing steps. It should be understood that such functional blocks may be implemented by any number of hardware and / or software components configured to perform the specified functions.

[0021] The scope of the present disclosure should be determined by the appended claims and their legal equivalents, rather than by the examples given herein. For example, the steps recited in any method claim may be performed in any order and are not limited to the order given in the claim. In addition, unless expressly described as "critical" or "essential" herein, no element is essential to the practice of the present disclosure.

[0022] As used herein, "network" or "computer network system" is a technical term that may refer to interconnected computing devices that can exchange data and share resources with each other. It should be understood that networked devices may use a system of rules (e.g., communication protocols, etc.) to transmit information through wired and / or wireless technologies.

[0023] As referred to herein, "NVMe protocol or interface" may refer to a non-volatile memory express protocol that provides a fast interface between a computer processing unit and a storage device, such as a solid-state device (SSD). The NVMe protocol or interface may use a peripheral component interconnect express (PCIe) bus that provides a more streamlined interface for accessing an SSD.

[0024] As referred to herein, "unified memory" may refer to a single memory address space accessible to any processor in a system, for example, a single memory address space shareable by a host device and a hardware offload engine. Unified memory may be stored / shared on various storage media, such as dynamic random access memory (DRAM), flash drives, high bandwidth memory (HBM), different memory spaces, shared memory spaces, memory on a network card, etc., for example, an addressable memory space.

[0025] As referred to herein, a "module" may refer to a network, an algorithm, a program, software, hardware, or any combination thereof that is configured or otherwise provided to perform the stated function.

[0026] In some computer network systems, such as cloud-based storage environments (e.g., in data centers), which use heterogeneous storage devices and storage devices, such as using different types of storage media (such as hard disk drives, solid-state devices, tape drives, etc.) for data storage, hardware offload operations can be provided so that a host device with a controller (such as a central processing unit (CPU)) can offload certain functions or operations from the host device to the controller (or CPU) on a server connected to (multiple) storage devices - for example, due to CPU limitations on the host device and / or optimizations for the host device. For example, in some embodiments, a server with a processor enabled with hardware, software, and / or firmware operations may include various hardware offload engines and / or accelerators, such as data flow accelerators, graphics processing units, memory analysis accelerators, etc., for performing certain functions or operations that might otherwise run on the CPU. In some embodiments, a host device may receive a request to support big data analytics, such as collecting, cleaning, analyzing, and / or processing one or more data streams, and the host device may then be configured to determine whether operations from the request should be offloaded to the hardware offload engine.

[0027] In some embodiments, the host device may be designed, programmed, or otherwise configured to provide (e.g., transmit / send) offload commands to the server so as to provide hardware offload operations / functionality to a hardware offload engine on the processor-enabled server (and / or the processor-enabled server may be designed, programmed, or otherwise configured to obtain offload commands).

[0028] Based on the communication protocol / interface between the host device and the server and / or the type of the hardware offload engine, the offload command may include (and / or be provided with) a pointer for a data source and / or a destination in a command descriptor format. The data location for processing (and / or writing) data by the hardware offload engine may be provided in various locations, including but not limited to a host-side memory, a device-side memory, a storage device, a unified memory, and the like.

[0029] However, in existing systems, in order to access a memory (or storage device) to retrieve (and / or write data), a different indexing method is used to access and / or identify each different type of memory or storage device, for example, involving multiple commands. For example, different commands are used to define data transfer for each direction, such as an input data source or an output data destination, where the greater the number of data location types, the more new commands may need to be defined. For example, in an example where the source location or the destination location can be one or more of a host memory, a device local memory, or a storage device, nine different possible data directions are provided, where the nine different possible data directions require separate commands to define the direction of the data, as shown in Table 1 below:

[0030]

[0031] In some embodiments, a non-volatile storage system may use a unified memory to provide a shared memory space where multiple heterogeneous computing devices (e.g., hardware accelerators and / or hardware offload engines) can access common data. Although the unified memory may provide access to common data, the unified memory may not allow the local memory of the device to be exposed and may only be applicable to byte-addressable memory. As such, a computer system or data center utilizing the unified memory may still require additional commands to access data from other data sources and / or access different output destinations, such as storage devices.

[0032] Methods, systems, and devices are described herein for optimizing a non-volatile storage system using hardware offload or hardware acceleration by utilizing a unified data pointer in an offload command for hardware acceleration and / or hardware offload operations, for example, in a heterogeneous storage device and storage device system having at least two types of data locations. The unified data pointer can be used to point to (multiple) specific memory locations where data is to be sourced from (e.g., read) or data needs to be stored (e.g., written) thereto. That is, the method, system, and device are designed, programmed, or otherwise configured to prepare and / or parse an offload command that includes a data field for identifying a source of input data and / or a destination of output data using a unified data pointer so that a single command can be used to represent all types of different data transfers / directions, for example, different storage devices / memory locations for reading / writing data, such as Table 1 and / or various devices from heterogeneous storage devices and storage device systems.

[0033] Figure 1 is a schematic diagram of an example cloud-based storage system 100 arranged in accordance with at least some embodiments described herein.

[0034] System 100 may include terminal devices 110, 120, 130, and 140, a network 160, a host controller 170 (eg, a host device), and (a plurality of) servers 150a...150n. It should be understood that Figure 1 Only exemplary numbers of terminal devices, networks, host devices, and (multiple) servers are shown. The embodiments described herein are not limited to the number of terminal devices, networks, host devices, and / or servers described. That is, the number of terminal devices, networks, host devices, and / or servers described herein is for illustrative purposes only and is not intended to be limiting.

[0035] According to at least some example embodiments, terminal devices 110, 120, 130, and 140 may be various electronic devices and / or digital or virtual devices. Various electronic devices may include, but are not limited to, mobile devices such as smartphones, tablet computers, e-book readers, laptop computers, desktop computers, and / or any other suitable electronic devices or hosts for browsers or applications.

[0036] According to at least some example embodiments, the network 160 may be a medium used to provide a communication link between the terminal devices 110, 120, 130, 140 and the servers 150a ... 150n. The network 160 may be the Internet, a local area network (LAN), a wide area network (WAN), a local interconnect network (LIN), a cloud, etc. The network 160 may be implemented by various types of connections, such as a wired communication link, a wireless communication link, a fiber optic cable, etc.

[0037] According to at least some example embodiments, host controller 170 may be a client or server that links servers 150a...150n together (e.g., in a data center), or links other host controllers (e.g., in other data centers). Host controller 170 may be designed, programmed, or otherwise configured to send and / or receive applications, services, data, etc. to connected devices / components.

[0038] According to at least some example embodiments, the servers 150a...150n may be servers for providing various services, such as servers for providing cloud services (including, for example, cloud storage, retrieval services, big data analysis, machine learning, data mining, etc.) to end users using one or more terminal devices 110, 120, 130, and 140. The servers 150a...150n may be implemented as a data center, which includes a distributed server cluster including multiple servers 150a...150n, or includes a single server. In some embodiments, one or more data centers may communicate with each other via a network 160. The servers 150a...150n may also include a controller for controlling hardware and / or storing software and firmware and providing the functionality of the server.

[0039] In some embodiments, the servers 150a...150n may include (multiple) storage devices, such as non-volatile memory (NVM) solid-state drives (SSDs), such as flash memory, or communicate with (multiple) storage devices using various communication interfaces that allow for rapid storage of data on (multiple) storage devices and / or retrieval of data from (multiple) storage devices. In some embodiments, the communication interface between the host device and the servers 150a...150n may be an NVMe or non-volatile memory host controller interface protocol. The NVMe protocol was developed in response to the need for a faster interface between a central processing unit (CPU) and an SSD. NVMe may be a logical device interface for accessing an SSD connected to a server controller, for example, via a fast peripheral component interconnect (PCIe) bus that provides a more streamlined interface for accessing the SSD.

[0040] End users may use one or more of the terminal devices 110, 120, 130, and 140 to interact with the servers 150a...150n via the network 160. In some embodiments, various applications, such as social media applications, social network applications, shopping applications, game applications, etc., may be installed on the terminal devices 110, 120 or may be accessible through the terminal devices 110, 120, 130, and 140. In some embodiments, end users may request big data analysis or data mining of data on storage devices connected to (multiple) servers 150a...150n and / or data residing on or provided to a cloud computing system to support data analysis, learning models, etc.

[0041] It is understood that the software application or service according to the embodiments described herein and / or according to the services provided by the cloud service provider can be executed by the host controller 170, the server 150a...150n and / or the terminal devices 110, 120, 130 and 140 (which may be referred to as user devices herein). Therefore, the device for the software application and / or service can be arranged in the host controller 170, the server 150a...150n and / or the terminal devices 110, 120, 130 and 140.

[0042] It will also be appreciated that, where services are not performed remotely, system 100 may not include network 160, but may include only terminal devices 110, 120, 130, and 140, host controller 170, and / or servers 150a...150n.

[0043] It can also be understood that the terminal devices 110, 120, 130 and 140, the host controller 170 and / or the server 150a...150n can each include one or more processors, firmware and a storage device storing one or more programs. The terminal devices 110, 120, 130 and 140, the host controller 170 and / or the server 150a...150n can also each include an Ethernet connector, a wireless fidelity receiver, etc. One or more programs, when executed by one or more processors, can cause one or more processors to perform the methods described in any of the embodiments described herein. In addition, it can be understood that a computer-readable non-volatile medium can be provided according to the embodiments described herein. The computer-readable medium stores a computer program. The computer program is used to perform the (multiple) methods described in any of the embodiments described herein when executed by a processor.

[0044] Figure 2 is a schematic diagram of example working nodes of a non-volatile storage device in a data center architecture 200 arranged according to at least some embodiments described herein.

[0045] The data center architecture 200 includes at least a host device 270, a hardware offload engine 220, and one or more storage devices 230A ... 230N. In an example embodiment, the data center architecture 200 may include one or more host devices 270 and / or one or more hardware offload engines 220, which may be located on or in communication with one or more of the servers, e.g. Figure 1 150a...150n in. The embodiments described herein are not limited to the number of host devices, hardware offload engines, and / or storage devices described. That is, the number of host devices, hardware offload engines, and / or storage devices described herein is for descriptive purposes only and is not intended to be limiting.

[0046] According to at least some example embodiments, the host device 270 may be Figure 1 150n) and can communicate with one or more of the servers (e.g., 150a...150n) and / or one or more of the hardware offload engines 220. In some embodiments, the host device 270 can be a controller, a central processing unit (CPU), or software on one or more of the servers or on a central node in the data center architecture 200. In some embodiments, the host device 270 can include a processor 271 and one or more software applications 272 for operating, manipulating, reading, writing, deleting, storing, or otherwise accessing data (and / or block addresses) on the host device 270 itself, the hardware offload engine(s) 220, and / or the storage devices 230A...230N. For example, when the host device 270 reads data from the storage devices 230A...230N, the host device 270 can receive data (e.g., stored on the device memory) from the hardware offload engine 220, or directly from the storage devices 230A...230N. When the host device 270 writes and / or provides a command to write data to the storage devices 230A ... 230N, the host device 270 may send the data and / or send the command with an output destination to the hardware offload engine 220 .

[0047] In some embodiments, the host device 270 may be designed, programmed or otherwise configured to support a big data analysis system and / or be combined with a business intelligence solution (e.g., data mining, predictive analysis, real-time analysis, etc.) that collects, processes, cleans and analyzes big data. In some embodiments, the host device 270 may be designed, programmed or otherwise configured to receive input data from an end user and / or retrieve input data (or addresses provided to input data) for big data analysis and / or business intelligence solutions, for example, input data stored in the host device 270 memory, the hardware offload engine 220 memory (e.g., device memory) and / or the storage device 230A...230N. The host device 270 may include one or more software applications 272 to support the big data analysis system on the front end (e.g., presentation layer), and may include one or more of the following: (multiple) application programming interfaces (APIs), (multiple) software development kits (SDKs), (multiple) device drivers 273, (multiple) runtime libraries, (multiple) software plug-ins, (multiple) management tools, etc. The API and / or SDK may be layered to provide a set of operations at different levels to the end user. These operations can be computationally intensive operations that require a lot of processing power, which are processed by a CPU, for example. In some embodiments, the API and / or SDK may be designed, programmed, or otherwise configured to convert operations into commands that the hardware can understand. (Multiple) runtime libraries may be provided to provide a set of low-level functions at runtime for resource scheduling and task management. (Multiple) software plug-ins may be provided to allow pluggable uninstallation for use cases. Management tools may be provided to monitor the health and / or performance of the data center architecture 200 and / or the components therein, and to manage jobs / operations for the components therein.

[0048] Device driver 273 may be provided to provide a software library for initializing the hardware and manage access to the hardware by higher software layers. In some embodiments, the device driver may be designed, programmed, or otherwise configured to provide a peripheral component interconnect (PCIe) device class hardware abstraction server for the hardware offload engine 220, which supports the NVMe protocol and / or supplier-specific commands for storage access and transmission. In this way, device driver 273 may be designed, programmed, or otherwise configured to communicate with the hardware offload engine 220 and / or server (e.g., 150a…150n), such as creating / sending / transmitting hardware offload commands and / or sending / receiving / deleting data. Although PCIe and NVMe protocols are discussed herein, this disclosure is not intended to be limiting, but other interface protocols may be used to communicate between the host device 270 and the hardware offload engine 220.

[0049] According to at least some example embodiments, the hardware offload engine 220 may be software or a card insertable into a server (e.g., 150a ... 150n), such as an add-on card (such as a PCIe card or a PCI card) to directly connect to or remotely connect to the storage devices 230A ... 230N and / or the host device 270, such as to communicate with the storage devices 230A ... 230N and / or the host device 270. The hardware offload engine 220 may include one or more interfaces in the interface 221, one or more processors in the processor, a CPU or a controller (e.g., double data rate (DDR) memory controller(s), system management bus (SMBUS) management controller(s), NVMe controller(s), etc.), firmware 222, a hardware accelerator module 223, a static random access memory (SRAM), a dynamic random access memory (DRAM), etc.

[0050] In some embodiments, the interface 221 may be designed, programmed or otherwise configured to provide communication with the host device 270, such as an interface for a motherboard assembly to provide a point-to-point connection and / or a remote connection. In some embodiments, the interface 221 may be a PCIe card, such as a slot interface with 16 channels. In some embodiments, the interface 221 may also be provided to communicate with the storage devices 230A ... 230N, and may be a PCIe card, such as a slot interface with 4 channels.

[0051] In some embodiments, the hardware accelerator module 223 may be designed, programmed or otherwise configured to perform hardware offload functions / operations. The hardware accelerator module 223 may include and / or be implemented as software, firmware, an application specific integrated circuit (ASIC), a graphics processing unit (GPU) and / or a field programmable gate array (FPGA), etc. The hardware accelerator module 223 may be connected to the host device 270 via the interface bus 221, wherein the hardware accelerator module 223 interfaces with the host device 270 via a device driver 273, which is specific to the specific software and hardware platform (e.g., for big data analysis) used for acceleration or hardware offload. Therefore, the hardware accelerator module 223 may be designed, programmed or otherwise configured to provide NVMe controller functionality to the host device 270 and / or act as a host of storage devices 230A...230N. In some embodiments, the hardware accelerator module 223 may include hardware-level functions, including but not limited to selection, decompression, compression, filtering, projection, aggregation, comparison, addition, subtraction, division, multiplication, shift, OR, XOR, data mining, data analysis, etc. In some embodiments, the hardware accelerator module 223 may be dynamically linked to form a pipeline of a given query execution framework, such as ASICs or FPGAs, and / or GPUs in series, in parallel, etc., and may also be reprogrammed when the end user wants (multiple) different executions (e.g., different operations to be offloaded).

[0052] In some embodiments, the firmware 222 may be provided on disk or as downloadable software on the hardware offload engine 220 for providing low-level control of device-specific hardware, such as on the hardware offload engine 220. In some embodiments, the firmware 222 may be designed, programmed or otherwise configured to manage multiple storage devices 230A...230N attached thereto and / or provide access to input data from a source location (or retrieve input data) or write output data to a destination location, such as a host memory, device memory or device storage. The firmware 222 may also be designed, programmed or otherwise configured to provide software control for the hardware accelerator module 223 to provide offload functionality / operations, and may include one or more of the following: a hardware abstraction layer (HAL) module, a front-end module, a core module, a monitoring module for monitoring the health / performance and management operations / jobs of the hardware offload engine 220, and a back-end module. Therefore, the firmware 222 can also be designed, programmed or otherwise configured to provide the hardware offload engine 220 with virtual NVMe storage functionality for the host device 270, management of multiple storage devices 230A...230N, and / or NVMe protocol offload functionality / operations, such as query offload functionality using the hardware accelerator module 223, for example for use in big data analytics acceleration processes.

[0053] The HAL module may include, but is not limited to, an SMBUS module, a non-volatile memory module, a serial peripheral interface (SPI) module, an input / output (I / O) engine module, a PCIe module, and an offload engine module for providing a software layer executed by the corresponding hardware. For example, in an embodiment, the HAL offload engine module may be designed, programmed, or otherwise configured as a driver layer to provide an API to the hardware accelerator module 223, such as execution instructions for performing offload functions / operations by an FPGA, ASIC, and / or GPU.

[0054] The front-end module may include, but is not limited to, one or more handler modules, including, but not limited to, a management command handler module, an I / O command handler module, a vendor command handler module, and an uninstall command handler module, which may be vendor-specific to provide a virtual NVMe device function and / or a software layer for command execution for associated hardware. For example, in an embodiment, an uninstall command handler module may be designed, programmed, or otherwise configured as a front-end module to obtain a host request (e.g., an uninstall command) and return a response to the request to the host device 270.

[0055] The core modules may include, but are not limited to, a core API module, a firmware manager module, a virtual namespace manager module, a metadata manager module, a telemetry and logging module, an SSD manager module, a card manager module, and a micro-query processor module for providing software and / or instructions to the hardware (e.g., core hardware, FPGA, ASIC, GPU, etc.) of the hardware offload engine 220. In an embodiment, for example, the micro-query processor module may be designed, programmed, or otherwise configured to provide instructions and / or commands for offloading functions / operations, such as processing offload execution, such as selection, comparison, decompression, compression, decoding, filtering, projection, and the like.

[0056] The back-end module may include, but is not limited to, an interface module 221 that communicates with the storage devices 230A…230N, such as a data access layer. In some embodiments, the interface module 221 may include software and / or provide instructions / executions to implement NVMe storage access and transfer protocols, such as a PCIe interface, for writing output data from the hardware offload engine 220.

[0057] According to at least some example embodiments, storage devices 230A...230N may include non-volatile memory (NVM), such as flash memory. As such, storage devices 230A...230N may be NVM solid state drives (SSDs), which may allow for faster storage and retrieval of data. As discussed above, storage devices 230A...230N may communicate with host device 270 via hardware offload engine 220.

[0058] Return to see Figure 2In an example embodiment of the acceleration process in the data center architecture 200, the host device 270 may provide (multiple) vendor-specific offload command entries for hardware offload functionality / operations (referred to herein as "offload operations"), and / or the hardware offload engine 220 may obtain (multiple) vendor-specific offload command entries for hardware offload functionality / operations (referred to herein as "offload operations"). The hardware offload command entries may be 32 bytes, 64 bytes, 128 bytes, 256 bytes, etc. to provide instructions for the hardware offload operations of the hardware offload engine. The hardware offload command entries may be provided in a command descriptor format and may include a hardware offload opcode (e.g., opcode) layer, an input pointer, an input size, an output pointer, and an output size, with 8, 16, 32, or 64-bit field entries or other sizes as needed, as further discussed below. That is, the size of a field entry is not limited to a specific bit field entry, but can depend on the nature of the source location and / or destination location, such as a memory address, the number of different source locations and / or destination locations, the specific transmission protocol used, etc., and can be defined or allocated based on the specific purpose of the protocol, such as provided in the protocol's instruction manual.

[0059] The hardware offload engine 220 may be designed, programmed or otherwise configured to then parse the hardware offload command entry to perform necessary operations based on the hardware offload command entry. In some embodiments, input data may be retrieved (or transmitted) from one or more input data sources for the hardware offload engine 220 (such as, memory on the host device 270, memory on the hardware offload engine 220, storage device 230A ... 230N, network storage or unified storage) so that, for example, via the hardware accelerator module 223, the hardware offload engine 220 may perform an offload operation on the input data. In some embodiments, the offload command received by the hardware offload engine 220 from the host device 270 may include an access address for accessing the input data, such as a file path, etc., wherein the hardware accelerator (or firmware) is designed, programmed or otherwise configured to access the file path, locate the input data being sought, read blocks related to the file data, perform acceleration processes or operations, and transmit output data, such as to the file path, etc.

[0060] For example, in an embodiment, when the parsing layer of the opcode from the hardware offload command entry is "projection", the hardware offload engine 220 can offload projection operations such as addition, subtraction, multiplication, comparison, filtering, XOR, decompression, compression, etc. from the host device 270, and can be designed, programmed or otherwise configured to initiate data transfer from a source location (e.g., memory on the host device 270 (and / or memory on the hardware offload engine 220, or storage devices 230A...230N)) and perform the offload operation, such as via an FPGA, ASIC and / or GPU. After at least one hardware accelerator module 223 performs the offload operation, the hardware offload engine 220 can be designed, programmed or otherwise configured to write the processed data to a destination source, such as memory on the host device 270, memory on the hardware offload engine 220, or storage devices 230A...230N based on the output pointer (and output size). In some embodiments, after the output data is written or after the offload operation is completed, a completion command can be returned to the host device 270.

[0061] Figure 3A , Figure 3B , Figure 3C , Figure 3D and Figure 4 An exemplary embodiment is shown in which a host device (eg, host device 470 (or Figure 2 host device 270)) and / or a hardware offload engine (e.g., hardware offload engine 420 (or Figure 2The hardware offload engine 220)) can be designed, programmed or otherwise configured to optimize the hardware offload or hardware acceleration process of the non-volatile storage system by utilizing (multiple) hardware offload commands, which hardware offload commands include a unified data pointer for identifying a source location or a destination location (e.g., a specific memory location from which data originates or to which data needs to be stored). For example, in some embodiments, a host device (e.g., host device 270 or host device 470) may be designed, programmed, or otherwise configured to offload operations from the host device (e.g., host device 270 or host device 470) to a hardware offload engine (e.g., hardware offload engine 220 or hardware offload engine 420), which may include one or more hardware accelerator modules, which may include and / or be implemented as software, firmware, an application-specific integrated circuit (ASIC), a graphics processing unit (GPU), and / or a field-programmable gate array (FPGA), etc., for example to offload computationally intensive operations that require a CPU to have a large amount of processing power from the host device (e.g., host device 270 or host device 470) to hardware on the hardware offload engine (e.g., hardware offload engine 220 or hardware offload engine 420). Thus, the host device 270 or 470 may be designed, programmed or otherwise configured to prepare a hardware offload command entry 302 to provide a set of instructions / operations for execution / offloading by a hardware accelerator module, such as on a hardware offload engine (e.g., hardware offload engine 220 or hardware offload engine 420). In an embodiment, the hardware offload command entry 302 may be in a command descriptor format and may include a field 305 including, but not limited to, a hardware offload operation type (e.g., an opcode), an input pointer, an input size of input data, an output pointer, an output size, and / or a flag, wherein data describing and / or characterizing the request (and / or input / output data) is used in corresponding fields of the hardware offload command entry. It should be understood that the fields described herein are not intended to be limiting, but are provided for illustrative purposes.

[0062] In some embodiments, to simplify commands for data transfer between different memory locations, input pointers and / or output pointers may use a unified indexing mechanism or a unified data pointer, such as a host-side memory pointer (e.g., a memory address in a computer main memory of a host device (e.g., host device 270 or host device 470)), a device-side memory pointer (a memory address in a hardware offload engine (e.g., hardware offload engine 220 or hardware offload engine 420)), and / or a storage pointer (a memory on a storage block 230A...230N or 430). Thus, by using a unified data pointer that points to a specific memory location from which data originates or to which data needs to be stored, the embodiments discussed herein use a single command entry that remains unchanged regardless of the source and / or destination of the data transfer. Thus, a data center architecture utilizing a unified data pointer may not have to use new and / or complex commands for each type of data transfer (e.g., different source or destination locations), but instead use a single command entry to identify the data transfer / direction, which may reduce software complexity and, for example, the software development effort of a programmer or developer.

[0063] For example, Figure 3AAs illustrated in , the hardware offload command entry 302 can be in a command descriptor format and can include fields 305, such as a hardware offload operation type (e.g., an opcode), an input pointer, an input size of the input data, an output pointer, an output size, and / or a flag. In some embodiments, at least one of the input pointer 312 and / or the output pointer 313 includes a unified data pointer B. The unified data pointer B may include one or more memory bits and may be used as an identifier for identifying and / or defining one or more source locations and / or destination locations, and may depend on the various devices in the heterogeneous storage device and storage device system. That is, the number of one or more memory bits used for the unified data pointer B may depend on the number of source locations and / or destination locations, for example, more memory may be allocated depending on the number or amount of source locations and / or destination locations of the various devices in the heterogeneous computing system. For example, in a non-limiting embodiment, the unified data pointer B can be used to define and / or identify memory on a host device (e.g., host device 270 or host device 470), memory on a hardware offload engine (e.g., hardware offload engine 220 or hardware offload engine 420), a storage device (e.g., storage device 230A...230N or 430), a unified memory, or other location with input data for processing by a hardware acceleration module or for writing output data from a hardware acceleration module. The unified data pointer B can be a portion or part of a memory (e.g., a memory address) of a command entry field for an input (or output) pointer, such as 2, 4, or 6 bits of a 64-bit field entry for an input pointer (or output pointer), and can be used as an identifier for a source of input data and / or a destination location for storing output data. In some embodiments, the unified data pointer B, which includes one or more memory bits, can include a binary 2-bit entry or identifier, such as 00, 10, 11, etc., for identifying a source location or a destination location.

[0064] For example, Figure 3B , Figure 3C , Figure 3DAs illustrated in , in some embodiments, binary bit entry "00" may indicate or define the source location and / or destination location as a memory on a host device (e.g., host device 270 or host device 470), bit entry "10" may indicate or define the source location and / or destination location as a memory on a hardware offload engine (e.g., hardware offload engine 220 or hardware offload engine 420), and bit entry "11" may indicate or define the source location and / or destination location as a storage device address. In some embodiments, unified data pointer B may be provided at the beginning of input pointer 312 or output pointer 313, such as an amount or portion of a memory address for input data or output data. Thus, when hardware offload command entry 302 is parsed (e.g., by a hardware offload engine (e.g., hardware offload engine 220 or hardware offload engine 420)) and / or prepared (e.g., by host device 270 or host device 470), unified data pointer B may be used as an indicator for providing (or identifying) remaining information (e.g., type) that input pointer 312 and / or output pointer 313 will use or is necessary, such as address, block number, device address, etc. For example, in an embodiment, when the binary bit entry is “00”, the host device (e.g., host device 270 or host device 470) and / or the hardware offload engine (e.g., hardware offload engine 220 or hardware offload engine 420) may be designed, programmed, or otherwise configured to understand that the bit entry “00” is being used to identify that input data (or output data) is being provided from (or being provided to) a memory in the host device (e.g., host device 270 or host device 470). As such, the host device (e.g., host device 270 or host device 470) and / or the hardware offload engine (e.g., hardware offload engine 220 or hardware offload engine 420) may be configured to understand and / or expect that input pointer 312 may further include a memory address of the host device. Similarly, in an embodiment, when the binary bit entry is "10", the host device (e.g., host device 270 or host device 470) and / or the hardware offload engine (e.g., hardware offload engine 220 or hardware offload engine 420) may be designed, programmed, or otherwise configured to understand that the bit entry "10" is being used to identify that input data (or output data) is being provided from (or being provided to) a memory in the hardware offload engine (e.g., hardware offload engine 220 or hardware offload engine 420). As such, a host device (e.g., host device 270 or host device 470) and / or a hardware offload engine (e.g., hardware offload engine 220 or hardware offload engine 420) can be configured to understand and / or expect that input pointer 312 can also include a device address and, for example, a local memory address on the hardware offload engine.In an embodiment, when the binary bit entry is "11", the host device (e.g., host device 270) and / or the hardware offload engine (e.g., hardware offload engine 220) may be designed, programmed, or otherwise configured to understand that the bit entry "11" is being used to identify that input data (or output data) is being provided directly from (or being provided directly to) a storage device (e.g., storage device 230A...230N or 430). In this way, the host device (e.g., host device 270 or host device 470) and / or the hardware offload engine (e.g., hardware offload engine 220 or hardware offload engine 420) may be configured to understand and / or expect that the input pointer 312 may further include a storage device address and block number of an associated storage device. In some embodiments, the unified data pointer B may include a defined identifier, for example, a binary bit entry or memory bit used to define or identify a source location and / or a destination location (e.g., provided based on a protocol for communicating with a non-volatile storage device and a device in a computing system).

[0065] It will be appreciated that although the unified data pointer B is described herein as a 2, 4, or 6-bit entry, this disclosure is not intended to be limiting. Instead, the size and / or use of the bit identifier (e.g., a 2-bit identifier) ​​used for the unified data pointer B may depend on the use and number of source / destination locations, where memories of different types, sources, or locations may be used for more complex situations, such as multiple data centers or server locations, one or more input (or output) data locations, and the like. That is, the size and / or number of bits used for the unified data pointer B are not limited herein, but are provided as exemplary embodiments, where the unified data pointer B may be determined by the number of memory locations used as source locations and / or destination locations. Thus, additional or new complex commands are not required for each type of data transfer, but a unified data pointer architecture may be used to simplify data transfer commands between different memory locations, which may reduce software complexity and / or the development workload of software, such as by a programmer or developer.

[0066] Figure 4 is a schematic diagram of example working nodes of non-volatile storage device(s) in a data center architecture 400 arranged in accordance with at least some embodiments described herein.

[0067] The data center architecture 400 includes at least a host device 470 , a hardware offload engine 420 , and one or more storage devices 430 .

[0068] According to at least some example embodiments, the host device 470 may be Figure 1 The host controller 170 or Figure 2The host device 270 can communicate with one or more of the servers (e.g., servers 150a...150n) and / or the hardware offload engine 420 (or Figure 2 In some embodiments, the host device 470 may be designed, programmed or otherwise configured to support a big data analytics system and / or to be combined with a business intelligence solution (e.g., data mining, predictive analytics, real-time analytics, etc.) that collects, processes, cleans and analyzes big data. In some embodiments, the host device 470 may be a controller, central processing unit (CPU), or software on one or more of the servers or on a central node in the data center architecture 400. In some embodiments, the host device 470 may include a processor and one or more software applications for operating, manipulating, reading, writing, deleting, storing, or otherwise accessing data (and / or block addresses) on the host device 470 itself, the hardware offload engine(s) 420, and / or the storage device 430. For example, when the host device 470 reads data from the storage device 430, the host device 470 may receive data (e.g., stored on the device memory) from the hardware offload engine 420, or directly from the storage device 430. When host device 470 writes and / or provides a command to write data to storage device 430 , host device 470 may send the data and / or send a command with a destination pointer for the output data to hardware offload engine 420 .

[0069] In some embodiments, the host device 470 may be designed, programmed or otherwise configured to receive input data from an end user and / or retrieve input data (or addresses provided to input data) for big data analysis and / or business intelligence solutions, such as input data stored in a host device 470 memory, a hardware offload engine 420 memory (e.g., device memory), and / or a storage device 430. The host device 470 may include one or more software applications to support a big data analysis system on a front end (e.g., presentation layer), and may include one or more of the following: (multiple) application programming interfaces (APIs), (multiple) software development kits (SDKs), (multiple) device drivers 273, (multiple) runtime libraries, (multiple) software plug-ins, (multiple) management tools, and the like. The API and / or SDK may be layered to provide a set of operations at different levels to the end user. These operations may be computationally intensive operations that require, for example, a large amount of processing power on a CPU. In some embodiments, the API and / or SDK may be designed, programmed or otherwise configured to convert operations into commands that the hardware can understand.

[0070] For example, in an embodiment, the host device 470 may receive a request to support big data analysis, such as collecting, processing, cleaning and / or analyzing one or more input data streams. The host device 470 may then be configured to receive, retrieve (e.g., read) or otherwise access the input data from different memory locations, wherein the SDK and / or API on the host device 470 may be designed, programmed or otherwise configured to analyze, process and / or determine data describing and / or characterizing the request (and / or for accessing the input data) from the request(s). Thus, the host device 470 may be configured to provide, send and / or prepare a hardware offload command entry 402 for the hardware offload engine 420 to perform a hardware offload operation. In some embodiments, the command entry 402 includes, but is not limited to, a hardware offload opcode (e.g., an opcode), an input pointer 412, an input size, an output pointer 413, an output size and / or a flag. The hardware offload opcodes may correspond to offload operations from the host device 470 , which may include, but are not limited to, selection, projection (such as addition, subtraction, multiplication), comparison, filtering, XOR, decompression or compression, and the like.

[0071] According to at least some example embodiments, the hardware offload engine 420 may be software or a card insertable into a server (e.g., servers 150a ... 150n), such as an add-on card (such as a PCIe card or a PCI card) to directly connect to or remotely connect to the storage device 430 and / or the host device 470, such as to communicate with the storage device 430 and / or the host device 470, or a combination thereof. The hardware offload engine 420 may include one or more of the interfaces, one or more of the processors, a CPU or a controller (e.g., double data rate (DDR) memory controller(s), system management bus (SMBUS) management controller(s), NVMe controller(s), etc.), firmware, a hardware accelerator module, a static random access memory (SRAM), a dynamic random access memory (DRAM), etc.

[0072] In some embodiments, the hardware accelerator module can be designed, programmed or otherwise configured to perform hardware offload functions / operations. The hardware accelerator module may include and / or be implemented as software, firmware, application specific integrated circuit (ASIC), graphics processing unit (GPU) and / or field programmable gate array (FPGA) and the like. The hardware accelerator module may be connected to the host device 470 via an interface bus, wherein the hardware accelerator module interfaces with the host device 470 via a device driver, and the device driver is specific to the specific software and hardware platform (e.g., for big data analysis) used for acceleration or hardware offload. In this way, the hardware accelerator module may be designed, programmed or otherwise configured to provide NVMe controller functions to the host device 470 and / or act as a host of the storage device 430. In some embodiments, the hardware accelerator module may include hardware-level functions, including but not limited to selection, decompression, compression, filtering, projection, aggregation, comparison, addition, subtraction, division, multiplication, shift, or (OR), XOR (XOR), data mining, data analysis, and the like.

[0073] In some embodiments, the firmware may be provided on disk or as downloadable software on the hardware offload engine 420 for providing low-level control of device-specific hardware (e.g., a hardware accelerator module). In some embodiments, the firmware may be designed, programmed, or otherwise configured to manage one or more storage devices 430 attached thereto and / or provide access to input data from a source location (or retrieve input data) or write output data to a destination location, such as a host memory, a device memory, or a device memory. The firmware may also be designed, programmed, or otherwise configured to provide software control of the hardware accelerator module to provide offload functionality / operations, and may include one or more of the following: a hardware abstraction layer (HAL) module, a front-end module, a core module, a monitoring module for monitoring the health / performance and management operations / jobs of the hardware offload engine 420, and a back-end module. Therefore, the firmware may also be designed, programmed, or otherwise configured to provide the hardware offload engine 420 with virtual NVMe storage functionality for the host device 470, management of one or more storage devices 430, and / or NVMe protocol offload functionality / operations, such as query offload functionality using a hardware accelerator module, for example for use in a big data analytics acceleration process.

[0074] According to at least some example embodiments, storage device 430 may include non-volatile memory (NVM), such as flash memory. As such, storage device 430 may be a NVM solid state drive (SSD), which may allow for faster storage and retrieval of data. As discussed above, storage device 430 may communicate with host device 470 via hardware offload engine 420.

[0075] Return to see Figure 4 In an example embodiment of a hardware offload or acceleration process in the data center architecture 400, the host device 470 and / or the hardware offload engine 420 may be designed, programmed, or otherwise configured to optimize the hardware offload or hardware acceleration process of a non-volatile storage system by utilizing (multiple) hardware offload commands that include a unified data pointer for identifying a source location and / or a destination location. In this way, a unified indexing mechanism or a unified data pointer may be provided to simplify parsing and / or preparation of offload commands (including data transfers using one or more memory locations), such as a host-side memory pointer (e.g., a memory address in a computer main memory of the host device 470), a device-side memory pointer (a memory address in the hardware offload engine 420), and a storage device 430. Thus, different commands and operations tailored for specific data transfers between different memory locations (e.g., separate commands for different data locations, such as transferring data from a main memory to a hardware offload engine 420 memory or vice versa) are unnecessary, which previously required increased complexity and possible inefficiencies in software or firmware development. That is, by using a unified data pointer pointing to a specific memory location where data originates from or needs to be stored, the embodiments discussed herein use a single command entry that remains unchanged regardless of the source and / or destination of the data transfer. Therefore, a data center architecture utilizing a unified data pointer may not have to use new and / or complex commands for each type of data transfer (e.g., different source or destination locations), but instead use a single command entry, which can reduce software complexity and software development workload. Although the unified data pointer B discussed herein can be used to identify different memory locations, this disclosure is not intended to be limiting, so the unified data pointer B can also be used to identify the same memory location, for example, both the input pointer and the output pointer include data from / to the host device. In some embodiments, the unified data pointer B can be used for a single command entry for a source location and a destination location, for example, two bit entries to the same address.

[0076] For example, in an embodiment, the host device 470 may provide (multiple) vendor-specific offload command entries 402 for hardware offload functionality / operation (referred to herein as "offload operation") (e.g., decompression), and / or the hardware offload engine 420 may obtain (multiple) vendor-specific offload command entries 402 for hardware offload functionality / operation (referred to herein as "offload operation") (e.g., decompression). The hardware offload command entry 402 may be provided in a command descriptor format having one or more fields 405 including, but not limited to, a hardware offload operation code (e.g., opcode), such as decompression, an input pointer 412, an input size, an output pointer 413, and an output size. In some embodiments, at least one of the input pointer 412 and / or the output pointer 413 includes a unified data pointer B. The unified data pointer B may include one or more memory bits that may be used as an identifier for identifying and / or defining one or more source locations and / or destination locations. The amount of one or more memory bits used for the unified data pointer B may depend on the number of source locations and / or destination locations, for example, more memory may be allocated depending on the number or amount of source locations and / or destination locations. For example, in a non-limiting embodiment, the unified data pointer B may be used to define and / or identify memory 474 on the host device 470, memory 424 on the hardware offload engine 420, and / or storage device 430, such as a block address. The unified data pointer B may be a portion or part of the memory of the command entry field for the input (or output) pointer, such as 2 bits of a 64-bit field entry for the input pointer (or output pointer), and may be used as an identifier for the source of input data or the destination location for storing output data. Although a 64-bit field entry for an input pointer (or output pointer) is discussed herein, such disclosure is not intended to be limiting, but rather may be understood as the size of the field entry depending on the type of transport protocol and may be defined by instructions for implementing such a protocol.

[0077] like Figure 4As illustrated in , when the input pointer 412 includes a unified data pointer B including a binary bit entry “11”, the hardware offload engine 420 may be designed, programmed, or otherwise configured to understand that the bit entry “11” is being used to identify that input data is provided on the storage device 430, so that the hardware offload engine 420 is configured to retrieve the input data from the storage device 430 at the block address identified in the input pointer 412. In this way, the hardware offload engine 420 (and / or the hardware accelerator module and / or firmware) is designed, programmed, or otherwise configured to access the file path at the block address, such as to locate the sought input data based on the input size, to select an appropriate or specific file, such as an 8, 32, 64, 128, or 256 MB file, from the starting address provided by the input pointer 412, read the blocks associated with the file data, and perform an accelerated process or operation, such as decompression. After the hardware offload engine 420 completes the offload operation, when the output pointer 413 includes a unified data pointer B containing a binary bit entry of "00", the hardware offload engine 420 can be designed, programmed or otherwise configured to understand that the bit entry "00" is being used to identify the destination location of the output data to be stored (or written) on the memory 474 on the host device 470, for example. In this way, the hardware offload engine 420 (and / or the hardware accelerator module) is designed, programmed or otherwise configured to write the output data to the file path at the host memory address with the corresponding data output size during the writing of the output data from the hardware offload engine 420 at the specified host memory address of the host memory 474 on the host device 470 provided in the output pointer 413, and the processed data size, for example, 8, 32, 64, 128 or 256MB file, can be used to determine the completion of the write starting from the starting address of the host memory address. In some embodiments, the host device 470 can know the output size before the hardware offload operation is completed. In some embodiments, the output size can be updated after the hardware offload engine 420 generates the output data. In other embodiments, for example, when the offload operation includes a read / write operation of output data on the storage device 430 after the hardware offload engine 420 completes the offload operation, the host device 470 may receive only the completion command.

[0078] Figure 5 is a flow chart illustrating an example process flow 500 of offload operations in a computer network system in accordance with at least some embodiments described herein.

[0079] It should be understood that the process flow 500 disclosed herein may be executed by one or more processors, such as a local device management CPU of a device, unless otherwise specified, including, for example, Figure 1(a) processor(s) of one or more devices 110, 120, 130, 140, 150a ... 150n and / or 170, Figure 6 The CPU 605 and / or any other suitable processor in.

[0080] It should also be understood that the processing flow 500 may include one or more operations, actions, or functions, as illustrated by one or more of blocks 510, 520, 530, 540, 550, and 560. Various of these operations, functions, or actions may correspond, for example, to software, firmware, program code, or program instructions executable by a processor, which cause these functions to be performed. Although illustrated as discrete blocks, obvious modifications may be made, for example, two or more blocks may be reordered; additional blocks may be added; and various blocks may be divided into more blocks, combined into fewer blocks, or eliminated depending on the desired implementation. It should be understood that prior to the processing flow 500, operations including initialization and the like may be performed. For example, system parameters and / or application parameters may be initialized. It should be understood that Figure 2-Figure 4 The processes, operations or actions described in the examples may be implemented or performed by (multiple) processors. The process flow 500 may start at block 510.

[0081] At block 510 (Prepare Unload Command), a processor on the host device (e.g., Figure 2 The host device 270 or Figure 4The host device 470) may be designed, programmed or otherwise configured to optionally prepare a hardware offload command, wherein the hardware offload command may include one or more of an opcode, an input pointer, an input size, an output pointer, an output size, and / or a flag. For example, as discussed above, the host device may be designed, programmed or otherwise configured to utilize a unified data pointer to identify the source of input data and / or the destination of output data so that a single command may be used to represent all types of different data transfers / directions, such as different storage / memory locations for reading / writing data. In an embodiment, the host device may be designed, programmed or otherwise configured to prepare a hardware offload command entry for an input pointer field with a unified data pointer. For example, in an embodiment, the host device may receive a request to support big data analysis, such as collecting, processing, cleaning and / or analyzing an input stream from a source location, the source location being selected from a memory on the host device, a memory on a hardware offload engine, a storage device, a unified memory, or other locations having input data for processing by a hardware acceleration module or for writing output data from a hardware acceleration module. The unified data pointer may be a quantity, portion, or part of a memory address for a source location and / or a destination location, and may include one or more memory bits for identifying a source location or a destination location, including a binary bit identifier, such as a binary 2-bit entry, for example, 00, 10, 11, etc. Thus, the host device may be configured to provide, send, and / or prepare, for example, a hardware offload command entry in a command descriptor format for the hardware offload engine to perform a hardware offload operation, the hardware offload command entry including fields, such as a hardware offload operation type (e.g., an opcode), an input pointer, an input size of input data, an output pointer, an output size, and / or a flag, wherein data describing and / or characterizing the request (and / or input data) is used in corresponding fields of the hardware offload command entry. It should be appreciated that while the unified data pointer B is described herein as a 2, 4, or 6-bit entry, such disclosure is not intended to be limiting. In contrast, the size and / or use of the bit identifier (e.g., a 2-bit identifier) ​​used for the unified data pointer B may depend on the use and number of source / destination locations, where memory of different types, sources, or locations may be used for more complex scenarios, such as multiple data centers or server locations, one or more input (or output) data locations, etc. That is, the size and / or number of bits used for the unified data pointer B is not limited herein, but is provided as an exemplary embodiment, where the unified data pointer B may be determined by the number of memory locations used as source locations and / or destination locations.Thus, for each type of data transfer, additional or new complex commands are not necessary, but the unified data pointer architecture can be used to simplify the data transfer commands between different memory locations, which can reduce software complexity and / or the development effort of the software by a programmer or developer, for example. Processing can proceed from block 510 to block 520.

[0082] At block 520 (Receive Offload Command), a processor on the hardware offload engine (e.g., Figure 2 Hardware offload engine 220 or Figure 4 The hardware offload engine 420 (located in the same data center or a second data center in communication with the data center) can be designed, programmed, or otherwise configured to receive and / or obtain a hardware offload command from a host device, wherein the hardware offload command includes at least an opcode, an input pointer, an input size, and an output size. The hardware offload engine can have an interface (e.g., interface 221) and / or a device driver (e.g., device driver 273) of the host device to communicate with the host device. Processing can proceed from block 520 to block 530.

[0083] At block 530 (Parse Offload Command), the processor on the hardware offload engine may be designed, programmed, or otherwise configured to parse the hardware offload command (e.g., in the format of a command descriptor) into different fields for operation / execution thereon. For example, in some embodiments, the hardware offload engine may parse the hardware offload command entry to identify the opcode, input pointer, input size, output pointer, and output size. In some embodiments, when the input pointer and / or output pointer are parsed, the input pointer may include a unified data pointer that identifies the source (or destination) of the input data (or output data) and the address for accessing the input data. For example, in some embodiments, a binary bit entry "00" may represent a memory on a host device (e.g., host device 270 or host device 470), a bit entry "10" may represent a memory on a hardware offload engine (e.g., hardware offload engine 220 or hardware offload engine 420), and a bit entry "11" may represent a storage device address. Therefore, at block 530, the hardware offload engine knows the operation to be offloaded to the hardware offload engine (e.g., based on the opcode) and the source of the input data for processing. Processing may proceed from block 530 to block 540 .

[0084] At block 540 (retrieve input data), a processor on the hardware offload engine may be designed, programmed, or otherwise configured to retrieve (or receive) input data based on an input pointer and an input size, such as from a specific memory location (e.g., a memory on a host device) specified by a unified data pointer and an address in the input pointer. In some embodiments, the hardware offload engine may be designed, programmed, or otherwise configured to retrieve / receive input data from the host device starting from a specified address at the input pointer and the indicated input size of the hardware offload command entry. In some embodiments, when the input data is stored in a memory on the host device, a device driver for the host device may be designed, programmed, or otherwise configured to transmit (or retrieve) input data based on a hardware offload command entry. In this manner, processing may proceed from block 540 to block 550.

[0085] At box 550, (perform an offload operation), the processor on the hardware offload engine can be designed, programmed or otherwise configured to perform an offload operation on the hardware offload engine based on the opcode on the input data. That is, after the hardware offload engine retrieves the input data from the host device (e.g., a specified memory location) or begins to retrieve the input data, the hardware offload engine can be designed, programmed or otherwise configured to, for example, perform an offload operation internally on the input data stream based on the opcode, such as performing selection, projection, etc. After performing the operation on the input data stream, the hardware offload engine can generate output data, which can be returned to the host device or written to a storage device. For example, in an embodiment, when the output pointer is parsed, the output pointer can include a unified data pointer to identify the destination of the output data, and an address for writing the output data. Therefore, the processor on the hardware offload engine can be designed, programmed or otherwise configured to write the output data based on the output pointer and the output size, such as starting to write the output data from a specific memory location (e.g., a memory on the host device) specified by the unified data pointer and the address in the output pointer. Therefore, processing can proceed from box 550 to box 560.

[0086] At box 560 (return completion status), the processor on the hardware offload engine and / or the processor on the host device may be designed, programmed or otherwise configured to optionally send a completion command after the offload operation is completed, such as when the offload operation includes a write operation to output data on, for example, a storage device or host device.

[0087] Figure 6 Arranged according to at least some embodiments described herein, suitable for implementing an electronic device (e.g., Figure 1 Schematic diagram of an example computer system 600 (one of the servers, host devices or terminal devices shown in FIG. 1 ). It should be understood that Figure 6 The computer system shown in FIG. 1 is for illustration only and is not intended to limit the functionality and applicability of the embodiments described herein.

[0088] As depicted, computer system 600 may include a central processing unit (CPU) 605. CPU 605 may perform various operations and processes based on programs stored in read-only memory (ROM) 610 or programs loaded from storage device 640 to random access memory (RAM) 615. RAM 615 may also store various data and programs required for the operation of system 600. CPU 605, ROM 610, and RAM 615 may be interconnected via bus 620. An input / output (I / O) interface 625 may also be connected to bus 620.

[0089] Components connected to the I / O interface 625 may also include: input devices 630, including keyboards, mice, digital pens, drawing boards, etc.; output devices 635, including displays such as liquid crystal displays (LCDs), speakers, etc.; storage devices 640, including hard disks, etc.; and communication devices 645, including network interface cards such as LAN cards, modems, etc. The communication device 645 can perform communication processing via a network (such as the Internet, WAN, LAN, LIN, cloud, etc.). In an embodiment, a drive 650 may also be connected to the I / O interface 625. Removable media 655, such as magnetic disks, optical disks, magneto-optical disks, semiconductor memories, etc., may be installed on the drive 650 as needed, so that a computer program read from the removable medium 655 may be installed in the storage device 640.

[0090] It should be understood that reference Figure 5 The processes described in the flowcharts and / or the processes described in other figures may be implemented as computer software programs and / or hardware. A computer program product may include a computer program stored in a computer-readable non-volatile medium. The computer program includes program code for executing the method shown in the flowchart and / or GUI. In this embodiment, the computer program may be downloaded and installed from a network via a communication device 645, and / or may be installed from a removable medium 655. When the computer program is executed by a central processing unit (CPU) 605, the above-mentioned functions specified in the method in the embodiments disclosed herein may be implemented.

[0091] Methods, systems and devices are described herein, which are directed to optimizing a non-volatile storage system using hardware offload or hardware acceleration by utilizing a unified data pointer in an offload command for hardware acceleration and / or hardware offload operations. The unified data pointer can be used to point to (multiple) specific memory locations where data is (e.g., read) from or data needs to be stored (e.g., written) therein. That is, the method, system and device are designed, programmed or otherwise configured to prepare and / or parse an offload command, which includes a data field for identifying the source of input data and / or the destination of output data using a unified data pointer, so that a single command can be used to represent all types of different data transfers / directions, for example, different storage / memory locations for reading / writing data. In this way, for each type of data transfer, additional or new complex commands are not necessary, but a unified data pointer architecture can be used to simplify data transfer commands between different memory locations, which can reduce software complexity and / or, for example, the development workload of software by a programmer or developer.

[0092] It should be understood that the disclosed and other solutions, examples, embodiments, modules and functional operations described in this document can be implemented in digital electronic circuits, or in computer software, firmware or hardware, including the structures disclosed in this document and their structural equivalents, or in a combination of one or more of them. The disclosed and other embodiments herein can be implemented as one or more computer program products, that is, one or more modules of computer program instructions encoded on a computer-readable medium, which are executed by a data processing device or control the operation of the data processing device. The computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter that affects a machine-readable propagation signal, or a combination of one or more of them. The term "data processing device" covers all devices, devices and machines for processing data, including, for example, a programmable processor, a computer or multiple processors or computers. In addition to hardware, the device may also include code that creates an execution environment for the computer program in question, for example, code that constitutes a processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.

[0093] A computer program (also referred to as a program, software, software application, script, or code) may be written in any form of programming language, including compiled or interpreted languages, and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program may be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files storing one or more modules, subroutines, or portions of code). A computer program may be deployed to execute on a single computer or on multiple computers located at a single site or distributed across multiple sites and interconnected by a communications network.

[0094] The processes and logic flows described in this document may be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows may also be performed by special purpose logic circuits, and the apparatus may also be implemented as special purpose logic circuits, such as field programmable gate arrays, application specific integrated circuits, and the like.

[0095] Processors suitable for executing computer programs include, for example, general-purpose and special-purpose microprocessors, and any one or more processors of any type of digital computer. Typically, the processor will receive instructions and data from a read-only memory or a random access memory or both. The basic elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices or operably coupled to receive data from or transfer data to or both of one or more mass storage devices for storing data, one or more mass storage devices such as magnetic disks, magneto-optical disks, or optical disks. However, a computer does not necessarily have such a device. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, including, for example, semiconductor memory devices, such as erasable programmable read-only memory, electrically erasable programmable read-only memory, and flash memory devices; magnetic disks, such as internal hard disks or removable disks; magneto-optical disks; and compact disk read-only memory and digital video disk read-only memory disks. The processor and memory can be supplemented by or incorporated into a dedicated logic circuit.

[0096] It should be understood that different features, variations and multiple different embodiments have been shown and described in various details. What is sometimes described in the present application in the form of specific embodiments is for illustrative purposes only and is not intended to limit or imply that only a specific embodiment or specific embodiments are envisioned. It should be understood that the present disclosure is not limited to any single specific embodiment or enumerated variation. Many modifications, variations and other embodiments will occur to those skilled in the art, and these modifications, variations and other embodiments are intended to and are actually covered by the present disclosure. In fact, indeed, the scope of the present disclosure should be determined by the appropriate legal interpretation and the construction (including equivalents) of the present disclosure as understood by those skilled in the art based on the complete disclosure present at the time of submission.

[0097] All aspects:

[0098] It should be understood that any aspects may be combined with each other.

[0099] Aspect 1. A hardware offload engine for performing an acceleration process, the hardware offload engine comprising: a hardware accelerator for performing the acceleration process, the hardware accelerator having a processor, the processor being configured to: receive a hardware offload command, the hardware offload command comprising an opcode, an input pointer for identifying a source location of input data of the hardware accelerator, and an output pointer for identifying a destination location of output data from the hardware accelerator, wherein at least one of the input pointer or the output pointer comprises a unified data pointer, the unified data pointer comprising one or more memory bits, the one or more memory bits being used to identify a source location of the input data or a destination location of the output data, parse the opcode, the input pointer and the output pointer from the hardware offload command, retrieve the input data based on the input pointer, and perform an offload operation on the input data based on the opcode.

[0100] Aspect 2. The hardware offload engine of aspect 1, wherein one or more memory bits of the unified data pointer define a host device memory, a hardware offload engine memory, or a non-volatile storage device block to identify a source of input data or a destination of output data.

[0101] Aspect 3. The hardware offload engine of any one of aspects 1-2, wherein the input pointer comprises a unified data pointer, and the input pointer further comprises a memory address for the input data.

[0102] Aspect 4. The hardware offload engine of aspect 3, wherein the input pointer comprises a memory address, and wherein the unified data pointer comprises one or more memory bits as part of the memory address for identifying a source of the input data.

[0103] Aspect 5. The hardware offload engine of Aspect 4, wherein the number of the one or more memory bits is determined by the number of source locations of the input data.

[0104] Aspect 6. The hardware offload engine of Aspect 4, wherein one or more memory bits include a binary 2-bit identifier, wherein the binary 2-bit identifier includes "00" to identify memory on the host device, "10" to identify memory on the hardware offload engine, and "11" to identify a non-volatile storage device.

[0105] Aspect 7. The hardware offload engine of any one of aspects 1-6, wherein the processor is further configured to write output data of the offload operation based on an output pointer, wherein the output pointer comprises a unified data pointer for identifying a destination of the output data.

[0106] Aspect 8. The hardware offload engine of Aspect 7, wherein the output pointer further includes a memory address for the output data.

[0107] Aspect 9. The hardware offload engine of aspect 8, wherein the unified data pointer comprises one or more memory bits as part of a memory address for identifying a destination of the output data.

[0108] Aspect 10. The hardware offload engine of aspect 9, wherein the number of the one or more memory bits is determined by the number of destination locations for the output data.

[0109] Aspect 11. The hardware offload engine of Aspect 9, wherein one or more memory bits include a binary 2-bit identifier, wherein the binary 2-bit identifier includes "00" to identify memory on the host device, "10" to identify memory on the hardware offload engine, and "11" to identify a non-volatile storage device.

[0110] Aspect 12. The hardware offload engine according to any one of aspects 1-11, wherein the hardware accelerator comprises one or more hardware accelerator modules for performing the offload operation so that the offload operation is offloaded from the host device.

[0111] Aspect 13. The hardware offload engine according to any of aspects 1-12, wherein the hardware offload command is received from a host device.

[0112] Aspect 14. The hardware offload engine according to any one of aspects 1-13, wherein the hardware offload command further includes an input data size and an output data size.

[0113] Aspect 13. A non-volatile storage device, comprising: a non-volatile storage device; and a controller, the controller comprising: a hardware offload engine for performing an acceleration process, the hardware offload engine comprising: a first interface for communicating with a host device; a second interface for communicating with the non-volatile storage device; and a hardware accelerator for performing the acceleration process, the hardware accelerator having a processor, the processor being configured to: receive a hardware offload command, the hardware offload command comprising an opcode, an input pointer for identifying a source location of input data for the hardware accelerator, and an output pointer for identifying a destination location of output data from the hardware accelerator, wherein at least one of the input pointer or the output pointer comprises a unified data pointer, the unified data pointer comprising one or more memory bits, the one or more memory bits being used to identify a source location for the input data or a destination location for the output data, parse the opcode, input pointer, input data size, output pointer, and output data size from the hardware offload command, retrieve the input data based on the input pointer and the input data size, and perform an offload operation on the input data based on the opcode.

[0114] Aspect 14. A hardware offload engine for performing an acceleration process, the hardware offload engine comprising: a hardware accelerator for performing the acceleration process, the hardware accelerator having a processor, the processor being configured to: receive a hardware offload command, the hardware offload command comprising an opcode, an input pointer for identifying a source location for input data, and an output pointer for identifying a destination location for output data, wherein at least one of the input pointer or the output pointer comprises a unified data pointer, the unified data pointer comprising one or more memory bits, the one or more memory bits being used to identify a source location for the input data or a destination location for the output data; and perform an offload operation on the input data based on the opcode.

[0115] Aspect 15. A method for performing an acceleration process by offloading an operation to a hardware offload engine, the method comprising: receiving a hardware offload command, the hardware offload command comprising an opcode, an input pointer for identifying a source location of input data, and an output pointer for identifying a destination location of output data, wherein at least one of the input pointer or the output pointer comprises a unified data pointer, the unified data pointer comprising one or more memory bits, the one or more memory bits being used to identify the source location of the input data or the destination location of the output data, parsing the opcode, the input pointer and the output pointer from the hardware offload command, retrieving the input data based on the input pointer, and performing an offload operation on the input data on the hardware offload engine based on the opcode.

[0116] Aspect 16. The method of aspect 15, further comprising writing output data of the offload operation from the hardware offload engine based on the output pointer, wherein the output pointer comprises a unified data pointer comprising one or more memory bits for identifying a destination of the output data.

[0117] Aspect 17. The method of aspect 16, wherein the output pointer further comprises a memory address for the output data.

[0118] Aspect 18. The method of aspect 17, wherein the unified data pointer includes one or more memory bits as part of a memory address for identifying a destination of the output data.

[0119] Aspect 19. The method of any one of Aspects 15-18, wherein retrieving input data based on the input pointer comprises the input pointer comprising a unified data pointer.

[0120] Aspect 20. The method of aspect 19, wherein the input pointer comprises a memory address, and wherein the unified data pointer comprises one or more memory bits as part of the memory address for identifying a destination for the output data.

[0121] Aspect 21. A host device configured to communicate with a non-volatile storage device, the host device comprising: a non-transitory computer-readable medium having computer-executable instructions stored thereon, the instructions, when executed, causing one or more processors to perform operations including: preparing a hardware offload command by providing an opcode, an input pointer for identifying a source location of input data of a hardware accelerator, and an output pointer for identifying a destination location of output data from the hardware accelerator, wherein at least one of the input pointer or the output pointer comprises a unified data pointer comprising one or more memory bits for identifying a source location of the input data or a destination location of the output data, sending a hardware offload command, and receiving a completion command.

[0122] Aspect 22. The host device of aspect 21, wherein one or more memory bits of the unified data pointer define a host device memory, a hardware offload engine memory, or a non-volatile storage device block to identify a source location of input data or a destination location of output data.

[0123] Aspect 23. The host device of any one of Aspects 21-22, wherein the input pointer comprises a unified data pointer for identifying a source of the input data, and the input pointer further comprises an address of the input data.

[0124] Aspect 24. The host device of any one of Aspects 21-23, wherein the output pointer comprises a unified data pointer for identifying a destination of the output data, and the output pointer further comprises an address of the output data.

[0125] Aspect 25. A non-transitory computer-readable medium having computer-executable instructions stored thereon, which instructions, when executed, cause one or more processors to perform operations including the following: receiving a hardware offload command, the hardware offload command including an opcode, an input pointer for identifying a source location of input data, and an output pointer for identifying a destination location of output data, wherein at least one of the input pointer or the output pointer includes a unified data pointer, the unified data pointer including one or more memory bits, the one or more memory bits being used to identify the source location of the input data or the destination location of the output data, parsing the opcode, the input pointer, and the output pointer from the hardware offload command, retrieving the input data based on the input pointer, and performing an offload operation on the input data on a hardware offload engine based on the opcode.

[0126] Aspect 26. The non-transitory computer-readable medium of Aspect 25, wherein the one or more processors are further configured to perform operations including the following: storing computer-executable instructions thereon, which instructions, when executed, cause the one or more processors to perform operations including the following: writing output data of the offload operation from the hardware offload engine based on an output pointer, wherein the output pointer includes a unified data pointer, which includes one or more memory bits for identifying a destination of the output data.

[0127] Aspect 27. The non-transitory computer-readable medium of any one of Aspects 25-26, wherein the output pointer further comprises a memory address for outputting the data.

[0128] Aspect 28. The non-transitory computer-readable medium of any one of Aspects 25-27, wherein retrieving input data based on the input pointer comprises the input pointer comprising a unified data pointer.

[0129] Aspect 29. The non-transitory computer-readable medium of Aspect 28, wherein the input pointer comprises a memory address, and the unified data pointer comprises one or more memory bits as part of the memory address for identifying a destination for the output data.

[0130] The terms used in this specification are intended to describe specific embodiments and are not intended to be limiting. Unless expressly stated otherwise, the terms "a", "an" and "the" also include plural forms. The terms "comprise" and / or "include" when used in this specification specify the presence of stated features, integers, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements and / or components.

[0131] With respect to the foregoing description, it should be understood that changes may be made to the details, particularly in the construction materials employed and the shapes, sizes and arrangements of parts, without departing from the scope of the present disclosure. This specification and the described embodiments are exemplary only, with the true scope and spirit of the present disclosure being indicated by the claims that follow.

Claims

1. A hardware offload engine for performing an acceleration process, the hardware offload engine comprising: A hardware accelerator for performing the acceleration process, wherein the hardware accelerator has a processor, and the processor is configured to: receiving a hardware offload command, the hardware offload command comprising an opcode, an input pointer for identifying a source location of input data to the hardware accelerator, and an output pointer for identifying a destination location of output data from the hardware accelerator, wherein at least one of the input pointer or the output pointer comprises a unified data pointer comprising one or more memory bits, the one or more memory bits being used to identify the source location of the input data or the destination location of the output data, parsing the opcode, the input pointer and the output pointer from the hardware offload command, retrieving the input data based on the input pointer, and An offload operation is performed on the input data based on the operation code.

2. The hardware offload engine of claim 1 , wherein the one or more memory bits of the unified data pointer define a host device memory, a hardware offload engine memory, or a non-volatile storage device block to identify the source of the input data or the destination of the output data. 3 . The hardware offload engine of claim 1 , wherein the input pointer comprises the unified data pointer, and the input pointer further comprises a memory address for the input data. 4 . The hardware offload engine of claim 3 , wherein the unified data pointer comprises, as part of the memory address, one or more memory bits for identifying the source of the input data. 5 . The hardware offload engine of claim 4 , wherein the number of the one or more memory bits is determined by the number of source locations for the input data.

6. The hardware offload engine of claim 4, wherein the one or more memory bits comprise a binary 2-bit identifier, wherein the binary 2-bit identifier comprises "00" to identify memory on a host device, "10" to identify memory on the hardware offload engine, and "11" to identify a non-volatile storage device.

7. The hardware offload engine of claim 1, wherein the processor is further configured to write the output data of the offload operation based on the output pointer, wherein the output pointer comprises the unified data pointer for identifying the destination of the output data.

8. The hardware offload engine of claim 7, wherein the output pointer further comprises a memory address for the output data.

9. The hardware offload engine of claim 8, wherein the unified data pointer comprises, as part of the memory address, one or more memory bits for identifying the destination of the output data.

10. The hardware offload engine of claim 9, wherein the number of the one or more memory bits is determined by the number of destination locations for the output data.

11. The hardware offload engine of claim 9, wherein the one or more memory bits comprise a binary 2-bit identifier, wherein the binary 2-bit identifier comprises "00" to identify memory on a host device, "10" to identify memory on the hardware offload engine, and "11" to identify a non-volatile storage device.

12. The hardware offload engine of claim 1, wherein the hardware accelerator comprises one or more hardware accelerator modules, the one or more hardware accelerator modules being configured to perform the offload operation so that the offload operation is offloaded from the host device.

13. A method for performing an acceleration process by offloading operations to a hardware offload engine, the method comprising: receiving a hardware offload command, the hardware offload command comprising an opcode, an input pointer for identifying a source location for input data, and an output pointer for identifying a destination location for output data, wherein at least one of the input pointer or the output pointer comprises a unified data pointer, the unified data pointer comprising one or more memory bits, the one or more memory bits for identifying the source location for the input data or the destination location for the output data, parsing the opcode, the input pointer and the output pointer from the hardware offload command, said retrieving input data based on said input pointer, and An offload operation is performed on the input data based on the operation code on the hardware offload engine.

14. The method of claim 13, further comprising writing the output data of the offload operation from the hardware offload engine based on the output pointer, wherein the output pointer comprises: The unified data pointer includes the one or more memory bits for identifying the destination of the output data.

15. The method of claim 14, wherein the output pointer further comprises a memory address for the output data.

16. The method of claim 15, wherein the unified data pointer includes, as part of the memory address, the one or more memory bits for identifying the destination of the output data.

17. The method of claim 13, wherein retrieving the input data based on the input pointer comprises: The input pointer comprises the unified data pointer.

18. The method of claim 17, wherein the input pointer comprises a memory address, and wherein the unified data pointer comprises, as part of the memory address, the one or more memory bits for identifying the source of the input data.

19. A host device, the host device being configured to communicate with a non-volatile storage device, the host device comprising: A non-transitory computer-readable medium having stored thereon computer-executable instructions that, when executed, cause one or more processors to perform operations comprising: preparing a hardware offload command by providing an opcode, an input pointer for identifying a source location of input data to the hardware accelerator, and an output pointer for identifying a destination location of output data from the hardware accelerator, wherein at least one of the input pointer or the output pointer comprises a unified data pointer comprising one or more memory bits for identifying the source location for the input data or the destination location for the output data, sending the hardware uninstall command, and Receive completion command.

20. The host device of claim 19, wherein the one or more memory bits of the unified data pointer define a host device memory, a hardware offload engine memory, or a non-volatile storage device block to identify the source location of the input data or the destination location of the output data.

Images