System and method for offloading application functions to a device

Abstract

A system and method for offloading an application function to a device is provided. The system includes a host device, a storage device including an embedded processor, and a bridge kernel device including a bridge kernel hardware and a bridge kernel firmware, wherein the bridge kernel device is configured to receive a plurality of variable parameters from the host device and transmit the plurality of variable parameters to the embedded processor for data processing.

Description

[0001] Cross-reference of related applications

[0002] This application claims priority and benefit to U.S. Provisional Patent Application No. 62 / 784,275, filed December 21, 2018, entitled “System and Method for Offloading Application Functions to a Device,” the entire contents of which are hereby expressly incorporated by reference. Technical Field

[0003] One or more aspects of embodiments of this disclosure relate to a system and method for unloading application functions to a device. Background Technology

[0004] In modern information technology (IT) infrastructure, relatively large amounts of data can be generated through various devices and processes. Examples of these data generators include smart devices (e.g., iPhones, iPads, etc.), autonomous vehicles, social networks, and Internet of Things (IoT) devices. Artificial intelligence (AI) and machine learning (ML) algorithms are being developed to analyze and utilize collected data to achieve greater application efficiency and productivity. Given recent developments in IT infrastructure, data processing and analysis may be necessary.

[0005] The information above in the Background Art section is only used to enhance the understanding of the background of the technology, and therefore should not be construed as an admission of the existence or relevance of the prior art. Summary of the Invention

[0006] The objective of this disclosure

[0007] Examples of embodiments of this disclosure may provide a system and method for unloading application functions to a device.

[0008] An aspect of exemplary embodiments of this disclosure relates to a system and method for offloading application functions to a device. According to some exemplary embodiments of this disclosure, a system includes: a host device; a storage device including an embedded processor; and a bridge kernel device including bridge kernel hardware and bridge kernel firmware, wherein the bridge kernel device is configured to receive a plurality of variable parameters from the host device and transmit the plurality of variable parameters to the embedded processor for data processing.

[0009] In some embodiments, implementation of the bridge kernel device is transparent to the host device, where the bridge kernel device is agnostic to a transport mechanism between the host device and the bridge kernel device, where the transport mechanism is one of a peripheral component interconnect express (PCIe) or an Ethernet connection. In some embodiments, the storage device is a solid state drive (SSD), and the embedded processor is a field programmable gate array (FPGA) processor or an SSD controller or a discrete co-processor, where: the embedded processor includes an offloaded application function configured to execute on the embedded processor, the embedded processor further includes bridge kernel firmware, the bridge kernel device transmits a plurality of variable parameters received from the host device to the offloaded application function, and the bridge kernel device extracts a plurality of variable parameters received from a host register interface of the host device.

[0010] In some embodiments, the storage device further includes a first in, first out (FIFO) register and a dynamic random-access memory (DRAM), the DRAM including a plurality of data buffers and a handshake region to store a plurality of variable parameters received from the host device, and where the FIFO register and the DRAM are communicatively coupled to the bridge kernel hardware. In some embodiments, the FIFO register is configured to transfer the plurality of variable parameters to the embedded processor incorporating the offloaded application function for data processing. In some embodiments, the bridge kernel hardware is configured to temporarily store the plurality of variable parameters received from the host device into the handshake region of the DRAM. In some embodiments, the bridge kernel device is configured to act as a proxy for a host application running on a client application module of the host device, where the host application is agnostic to where or how the offloaded application function is implemented.

[0011] In some embodiments, the host device includes a client application module and an OpenCL module, and wherein the host device is configured to establish a PCIe or Ethernet connection with the storage device. In some embodiments, the bridge kernel hardware includes a plurality of hardware kernels and the bridge kernel firmware includes a plurality of software kernels, the plurality of software kernels configured to run on an embedded processor, wherein a host application running on the client application module of the host device is configured to interface with the plurality of software kernels and / or hardware kernels through the OpenCL module. In some embodiments, the bridge kernel device is configured to select one or more kernels from among the plurality of hardware kernels and the plurality of software kernels for data processing based on a cost function.

[0012] In some embodiments, the bridge kernel device is configured to select one or more kernels for data processing based on a cost function using a plurality of variable parameters and storage parameters or networking parameters received from the host device, wherein the storage parameters or networking parameters received from the host device include at least one of a Submission Queue Identifier (SQID), a Completion Queue Identifier (CQID), a stream ID, a host ID, a Logical Block Address (LBA) range, a Network Service ID (NSID), a Media Access Control (MAC) ID, Transmission Control Protocol (TCP) / Internet Protocol (IP) fields, an application type, an application identifier, or a time and date associated with the host device. In some embodiments, the bridge kernel device is configured to select one or more kernels from among the plurality of hardware kernels and the plurality of software kernels for data processing using a FIFO register. In some embodiments, the bridge kernel firmware is configured to extract the plurality of variable parameters in a handshake region of the DRAM and invoke an offloaded application function using the plurality of variable parameters received from the host device. In some embodiments, the offloaded application function is configured to use the plurality of variable parameters for data processing.

[0013] According to some example embodiments of the present disclosure, a method includes receiving, by a bridge kernel device in a storage device, a trigger from a host device connected to the storage device; extracting, by the bridge kernel device, a plurality of variable parameters received from the host device, wherein the bridge kernel device is configured to extract the plurality of variable parameters from a host register interface; storing, by the bridge kernel device, the plurality of variable parameters in a dynamic random access memory (DRAM) of the storage device, wherein the plurality of variable parameters are stored in a handshake region of the DRAM; setting, by the bridge kernel device, a ready flag in the DRAM, wherein the ready flag is set in the handshake region of the DRAM; polling, by the bridge kernel device, a completion flag in the DRAM based on the bridge kernel device determining that processing of an offloaded function in firmware of the bridge kernel device in an embedded processor of the storage device based on the plurality of variable parameters is complete, wherein the completion flag is polled in the handshake region of the DRAM; and setting, by the bridge kernel device, the ready flag in the host register interface.

[0014] In some embodiments, the method further includes reading, by the bridge kernel device, an error or status from the handshake region of the DRAM based on detecting the completion flag in the handshake region of the DRAM; and updating, by the bridge kernel device, the error or status into the host register interface. In some embodiments, the method further includes polling, by the firmware of the bridge kernel device, the ready flag in the DRAM; extracting, by the firmware of the bridge kernel device, the plurality of variable parameters in the handshake region of the DRAM; invoking, by the firmware of the bridge kernel device, an offloaded application function in the embedded processor of the storage device using the plurality of variable parameters for data processing; returning, by the offloaded application function, the invocation to the firmware of the bridge kernel device based on completion of the data processing; and setting, by the firmware of the bridge kernel device, a completion flag in the handshake region of the DRAM.

[0015] According to some example embodiments of the present disclosure, a system includes a storage device including an embedded processor; and a bridge kernel device configured to receive a plurality of variable parameters from a host device and transmit the plurality of variable parameters to the embedded processor for data processing. In some embodiments, the bridge kernel device includes a bridge kernel hardware and a bridge kernel firmware, wherein the storage device is a solid state drive (SSD), and the embedded processor is a field programmable gate array (FPGA) processor or an SSD controller or a discrete co-processor, wherein the embedded processor includes an offloaded application function configured to execute on the embedded processor, the embedded processor further includes the bridge kernel firmware, and wherein the bridge kernel device transmits the plurality of variable parameters received from the host device to the offloaded application function configured to execute on the embedded processor, wherein the bridge kernel device extracts the plurality of variable parameters received from the host device from a host register interface.

[0016] In some embodiments, the storage device further includes a first-in-first-out (FIFO) register and a dynamic random access memory (DRAM), wherein the DRAM further includes a plurality of data buffers and a handshake region, wherein the FIFO register and the DRAM are communicatively coupled to the bridge core hardware, wherein the bridge core hardware includes a plurality of hardware cores and the bridge core firmware includes a plurality of software cores, the plurality of software cores configured to run in the embedded processor, wherein the bridge core device is configured to select one or more cores from the plurality of hardware cores and the plurality of software cores for data processing based on a cost function using a plurality of variable parameters and storage or networking parameters received from the host device, wherein the storage or networking parameters received from the host device are at least one of a submission queue identifier (SQID), a completion queue identifier (CQID), a flow ID, a host ID, a logical block address (LBA) range, a network service ID (NSID), a media access control (MAC) ID, a transmission control protocol (TCP) / internet protocol (IP) field, an application type, an application identifier, or a time and date associated with the host device, and wherein the bridge core device is configured to select one or more cores from the plurality of hardware cores and the plurality of software cores for data processing using the FIFO register.

[0017] Effects of the disclosure

[0018] The present invention can use software-based offloaded functions to reuse the software code that has already been performing those functions on the host. Further, the present invention can maintain the interface between the host software stack and the offloaded kernel to be the same as the software kernel and as any other form of kernel implementation. Thus, the initial fast offload can be performed in the form of a software kernel, and later the offloaded functions can be implemented in hardware without significantly changing or disrupting the overall host software stack and / or system architecture. By having the fast offload up and running, other system activities (e.g., system integration, validation, characterization, etc.) can be performed while more high performance kernels are being developed.

[0019] In other words, the present invention can offload application functions to a compute storage device, such as an SSD with an embedded processor, for efficient and cost-effective data processing. BRIEF DESCRIPTION OF DRAWINGS

[0020] These and other features and characteristics of some example embodiments of the present disclosure will become more apparent from the embodiments described herein, the claims, and the accompanying drawings, wherein:

[0021] FIG. 1A An example block diagram of a system including a bridge core is shown.

[0022] FIG. 1BAn example of cost-based routing of different kernels through the bridge kernel is shown.

[0023] FIGS. 2A-2B An example flow of a host application interfacing with an offloaded kernel is shown.

[0024] FIG. 3 An example of a register interface presented to the host through the bridge kernel is shown.

[0025] FIG. 4 An example of the layout of a handshake region as depicted in FIG. 1A

[0026] FIG. 5 An example of a method using the bridge kernel hardware as a state machine is shown.

[0027] FIG. 6 Bridge kernel firmware operations are shown.

[0028] BRIEF DESCRIPTION OF DRAWINGS

[0029] 100: system;

[0030] 102: host;

[0031] 104: storage;

[0032] 106: user application;

[0033] 108: Open Computing Language module;

[0034] 110: bridge kernel hardware;

[0035] 112: embedded processor;

[0036] 114: offloaded application function;

[0037] 116: bridge kernel firmware;

[0038] 118: first-in-first-out register;

[0039] 120: dynamic random access memory;

[0040] 122: data buffer;

[0041] 124: handshake region;

[0042] 126(1), 126(m), 126(n), 126(n+1): kernels;

[0043] 128: "ready" flag;

[0044] 130: "done" flag;

[0045] ​132: Error and / or other status;

[0046] 134: Host application software;

[0047] 136: Host upper-layer software;

[0048] 200, 500: Methods;

[0049] 201, 202, 203, 204, 205, 206, 207, 208, 501, 502, 503, 505, 507, 509, 511, 601, 603, 605, 607, 609, 611: Steps;

[0050] 300: Register interface;

[0051] 608: Example. Detailed Implementation

[0052] The specific embodiments described below with reference to the accompanying drawings are intended as descriptions of some exemplary embodiments of systems and methods for offloading application functions to a device according to the present disclosure, and are not intended to represent the only form in which the present disclosure can be constructed or utilized. The description is used to illustrate features of the present disclosure in conjunction with the illustrated embodiments. However, it will be understood that the same or equivalent functionality and structure can be achieved through different embodiments, which are also intended to be covered within the scope of the present disclosure. As indicated elsewhere herein, the same element numbers are intended to indicate the same element or feature.

[0053] In some system architectures, data can be retrieved from persistent storage to relatively high-performance servers, which can be connected to the storage via a high-performance network. Moving such large amounts of raw data to a central processing unit (CPU) for processing and analysis can be expensive in terms of the amount of energy consumed and the deployed computing and network resources. This movement of large amounts of raw data can increase the burden on resources such as network bandwidth, CPU cycles, and CPU memory. Moving large amounts of raw data to servers for processing can also increase the latency experienced by applications running on those servers.

[0054] In some cases, applications may need to wait for data to be retrieved to a server before processing and decision-making can be completed. These added resource requirements can lead to higher capital expenditures and operating costs. Therefore, processing raw data within storage devices (e.g., solid-state drives (SSDs)) whenever possible represents a cost-effective solution for many data analytics use cases, such as those targeting the monetization of growing volumes of raw data. Additionally, reducing data movement improves system latency for running applications.

[0055] Further, systems that employ data analytics tasks can often read relatively large amounts of data, process the data, and simplify the data through filtering and other data simplification operations. These and many other similar tasks can be implemented using SSD-based services because these tasks can take advantage of the higher available bandwidth within a device (e.g., an SSD) and save the limited bandwidth (e.g., a Peripheral Component Interconnect Express (PCIe) interface or a network fabric interface in the case of remote direct attached storage (RDAS)) between the SSD and the CPU by moving only the simplified results. Thus, techniques for processing data closer to or within a storage device (e.g., an SSD) are efficient and cost-effective for the need of data processing.

[0056] Some embodiments of the present disclosure include methods and systems for offloading application functions to computing storage devices (e.g., SSDs with embedded processors), which can produce efficient and cost-effective data processing solutions in some instances. Intelligent storage devices (e.g., SSDs with embedded processors) can provide a platform for performing at least a portion of data processing functions that can otherwise be performed by host CPU processors. Performing those data processing functions within an intelligent SSD or similar storage device can provide benefits to a storage network in terms of energy consumption, network bandwidth, CPU cycles, memory, etc.

[0057] In some instances, offloaded functions can be implemented using register transfer level (RTL) logic, high-level synthesis (HLS), or field programmable gate array (FPGA) logic in a storage device with embedded processors (e.g., FPGAs or SSD controllers or discrete co-processors) to improve performance and reduce power consumption of a storage network. However, the longer development cycle of high-performance offloaded functions using RTL or HLS can hinder or significantly slow down other activities of system development. Some embodiments of the present disclosure can enable offloaded functions to be executed on embedded processors (e.g., in SSDs) as software (also referred to as firmware) functions. By executing offloaded functions as software, a fast development time can be achieved. Software-based offloaded functions can also enable reuse of software code that already performs those functions on a host (e.g., a host CPU).

[0058] Performing offloaded functions as software or firmware in the embedded processor of a storage device or SSD can keep the interface between the host software stack and the offloaded kernel the same as the software kernel, as well as the same as any other form of kernel implementation. Thus, an initial fast offload can be in the form of a software kernel, and later the offloaded functions can be implemented in hardware without significantly altering or disrupting the overall host software stack and / or system architecture. By having a fast offload up and running, other system activities (e.g., system integration, validation, characterization, etc.) can be performed while a more high performance kernel is being developed.

[0059] As mentioned above, some embodiments of the present disclosure include methods and systems for offloading application functions to a computing storage device (e.g., an SSD with an embedded processor (e.g., an FPGA or SSD controller or discrete co-processor)) for efficient and cost-effective data processing. Some embodiments can include an FPGA hardware-based bridge kernel that can act as a proxy for the offloaded functions on behalf of the host (e.g., host CPU). The bridge kernel can accept variable parameters from the host driver and can transfer those variable parameters (e.g., parameter values, memory pointers, etc.) to the offloaded functions that will be executed as a software kernel on the embedded processor (e.g., FPGA or SSD controller or discrete co-processor). Hardware and firmware pieces in other embodiments can act as a bridge between the application running on the host and the software kernel. This software kernel can then be moved into hardware at a later point in time for host-transparent high performance. Thus, the bridge kernel host interface can be used without further modification, which can enable users of a computing storage device (e.g., a smart SSD) to quickly develop use cases, for example, by porting their existing application function encoding base to the embedded processor (e.g., FPGA or SSD controller or discrete co-processor) in the storage device.

[0060] This ease of use case development for a smart SSD can permit users to more quickly adopt the technology described herein. High performance kernels using HLS and RTL can take a relatively large amount of development time and resources. Example embodiments of the present disclosure can enable users to perform various tasks (e.g., system integration, customer demonstrations, system validation, and other tasks) while a high performance kernel is being developed in the background. Additionally, the bridge kernel can perform cost-based routing to different kernels. That is, the bridge kernel can invoke different kernels based on the variable parameters received from the host and some functions of the various storage parameters or networking parameters configured in the storage device with an embedded processor. For example, in some embodiments, based on the variable parameters received from the host during runtime, the bridge kernel can invoke different performance levels of kernels as appropriate.

[0061] FIG. 1AAn example block diagram of a system including a bridge kernel is shown. The system 100 includes a host 102 and a storage device 104 (e.g., a smart SSD, such as a fabric over Non-Volatile Memory express (NVMe) (Non-Volatile Memory express over Fabrics; NVMe-oF) compliant Ethernet SSD (Ethernet SSD; eSSD) with an FPGA processor, or an NVMe SSD with acceleration capabilities). The host 102 includes a module of a user application 106 and an OpenCL module 108. The OpenCL module 108 can be used to represent a compute offload application programming interface (e.g., this can apply to any compute offload interface between the host 102 and the storage device 104 (e.g., SSD)). The host 102 can establish a connection with the storage device 104 using a Peripheral Component Interconnect Express (PCIe) or Ethernet connection.

[0062] The storage device 104 includes a bridge kernel. In some embodiments, the bridge kernel can include a bridge kernel hardware 110 and a bridge kernel firmware 116. The storage device 104 further includes an embedded processor 112, a first-in-first-out (FIFO) register 118, and a dynamic random access memory (DRAM). The DRAM 120 includes a data buffer 122 and a handshake region 124. The embedded processor 112 includes an offloaded application function 114 and the bridge kernel firmware 116.

[0063] In some embodiments, the host 102 in the system 100 can further include an operating system (OS) and a file system (FS), as well as an NVMe-oF driver. In some embodiments, the storage device 104 can be inside a chassis (not shown) that includes an Ethernet switch, a baseboard management controller (BMC), and a PCIe switch. The Ethernet switch provides Ethernet connectivity to the storage device 104 (e.g., a smart SSD) through the midplane, and the PCIe switch provides a management interface to the storage device 104 through the midplane. The BMC can program the storage device 104 according to instructions given by a system administrator. The BMC can manage the internal components of the chassis that includes the Ethernet switch, the PCIe switch, and the storage device 104. The BMC can support a PCIe and / or a system management bus (SMBus) interface for system management. The BMC can configure the storage device 104 and program the Ethernet switch. In some embodiments, the Ethernet switch provides network connectivity between the host 102 and the storage device 104.

[0064] FIG. 1B Cost-based routing of different kernels of offloaded functions by a bridge kernel (e.g., bridge kernel hardware 110) is shown. In some embodiments, the system 100 enables relatively fast porting of offloaded functions (e.g., offloaded application functions 114) to storage devices, such as smart SSDs (e.g., storage device 104). In some embodiments, a user application 106 running on a CPU of a host (e.g., host 102) can benefit from offloading some of the functions to a smart SSD (e.g., storage device 104). In general, functions that process large amounts of data stored in an SSD (e.g., storage device 104) can benefit from such offloading. Offloaded functions (e.g., offloaded application functions 114) can be referred to as “kernels” (e.g., kernel 126(1), …, kernel 126(n), kernel 126(n+1), …, kernel 126(m)).

[0065] In FIG. 1BIn some embodiments, the kernels 126(1),..., 126(n), 126(n+1),..., 126(m) can be software kernels and the bridge kernel hardware 110 can be a hardware kernel. The software kernels among the kernels 126(1),..., 126(n) can run on the embedded processor 112. The host application (e.g., running in the user application 106) can interface with the kernels (e.g., the kernels 126(1),..., 126(n), 126(n+1),..., 126(m)) through an interface provided by a language like OpenCL (e.g., the OpenCL module 108) on the host 102 side and through the bridge kernel hardware 110 on the storage 104 side.

[0066] In some embodiments, a plurality of the kernels among the kernels 126(1),..., 126(n), 126(n+1),..., 126(m) can be high performance kernels (e.g., the high performance kernels can have a performance metric above a set or predetermined threshold) and other plurality of the kernels among the kernels 126(1),..., 126(n), 126(n+1),..., 126(m) can be low performance kernels (e.g., the low performance kernels can have a performance metric below a set or predetermined threshold). The bridge kernel (e.g., the bridge kernel hardware 110) can select one or more kernels from among the kernels 126(1),..., 126(n), 126(n+1),..., 126(m) for data processing.

[0067] In some embodiments, the bridge kernel can select the kernels for data processing based on a cost function. In some embodiments, the cost function can be determined based on a variable parameter received from the host 102 and a storage parameter or a networking parameter received from the host 102. Examples of the storage parameter or the networking parameter can include, but are not limited to, a submission queue identifier (SQID), a completion queue identifier (CQID), a stream ID, a host ID, a logical block address (LBA) range, a network service ID (NSID), a media access control (MAC) ID, a transmission control protocol (TCP) / internet protocol (IP) field, an application type, an application identifier, a time and / or date associated with the host 102, a combination thereof, and / or the like.

[0068] For example, variable parameters can be passed from the application side of the host 102 to the bridge kernel (e.g., the host's 102 application can offload a cost function to the bridge kernel hardware 110). The bridge kernel can compute the cost of using a given kernel. The bridge kernel can then select the best kernel based on the combination of the cost function and the storage parameters or networking parameters received from the host 102. In some embodiments, for example, the storage device 104 can implement two data compression kernels, one designed for better throughput and the other designed for better compression ratio. For a given run-time invocation of compression from the host 102, the bridge kernel can inspect the length variable parameter and can select the better compression ratio kernel whenever the length is greater than, for example, 64 kilobytes, and can select the other type of compression kernel for the rest. In some embodiments, the bridge kernel hardware 110 can select the best kernel from among the kernels 126(1),..., 126(n), 126(n+1),..., 126(m) for data processing using FIFO registers.

[0069] FIGS. 2A-2B An example flow of a host application (e.g., user application 106) interfacing with an offloaded kernel, such as method 200, is shown. At step 201, the bridge kernel (e.g., bridge kernel driver) can receive a call or invocation from an upper layer (e.g., host upper layer software 136, as illustrated in FIG. 3). FIG. 4 At step 202, the bridge kernel (e.g., bridge kernel driver) can store host variable parameters (e.g., variable parameter-1,..., variable parameter-n) into a host register interface (e.g., host register interface 300 of FIG. 3). FIG. 3 At step 203, the bridge kernel (e.g., bridge kernel driver) can allocate a buffer (e.g., data buffer 122) for data processing. At step 204, the bridge kernel (e.g., bridge kernel driver) can initialize other variable parameters required by the offloaded application function 114. At step 205, the bridge kernel (e.g., bridge kernel driver) can fetch data into the buffer for processing. At step 206, the bridge kernel (e.g., bridge kernel driver) can invoke the processing kernel. Once data processing is complete, the system 100 can perform a clean-up operation at step 207. At step 208, the offloaded application function 114 can return the call to the upper layer application software through the bridge kernel (e.g., bridge kernel driver).

[0070] In some embodiments, the bridge kernel can provide a general purpose register interface to the host 102. FIG. 3An example of a register interface 300 presented to host 102 via a bridge kernel is shown. Register interface 300 may reside in storage device 104. System 100 may use register interface 300 (e.g., as...) FIG. 3 As illustrated, the kernel is presented to a host application (e.g., running in user application 106) to pass variable parameters to an unloaded function (e.g., unloaded application function 114) and retrieve the returned values ​​or status. In some embodiments, system 100 may use the platform of OpenCL module 108 to facilitate kernel buffer allocation.

[0071] FIG. 4 Show FIG. 1A An example of the layout of the handshake area 124 of DRAM 120. For example... FIG. 4 As shown, in some embodiments, the bridge kernel hardware 110 may temporarily store variable parameters (e.g., variable parameter -1...variable parameter -n) received from the host 102 in a set or predetermined memory location in the DRAM 120 of the storage device 104 (e.g., a smart SSD). In some embodiments, the on-chip FIFO register 118 may be configured to transfer variable parameters to the embedded processor 112, which is incorporated into the unloaded application function 114, firmware, and bridge kernel firmware 116, instead of the DRAM 120.

[0072] The contents of register interface 300 (e.g., variable parameters -1 to -n) can be temporarily stored in the handshake area 124 of DRAM 120. Once the variable parameters are temporarily stored in DRAM 120, bridge core hardware 110 can set a "ready" flag 128 in the handshake area 124 of DRAM 120. At this point, bridge core hardware 110 can wait for the unloaded function running on firmware (e.g., bridge core firmware 116) to complete processing. Therefore, to determine the completion of the unloaded function processing, bridge core hardware 110 can poll the "complete" flag 130 in the handshake area 124 of DRAM 120.

[0073] Once the bridge kernel hardware 110 detects the "completion" flag 130, it can read any errors or other statuses from the handshake area 124 of DRAM 120. The bridge kernel hardware 110 then updates the register interface 300 with the error and / or other statuses 132 (e.g., ...). FIG. 3 The corresponding register (as shown in the diagram) is then set in the register of the "completion" flag 130, which can then be polled by the host application software 134 to indicate the completion of the unload function call.

[0074] FIG. 5This illustrates a method 500 using bridge kernel hardware as a state machine. The bridge kernel hardware can be... FIG. 1A The bridge kernel hardware 110.

[0075] At step 501, the bridge kernel hardware 110 remains in an idle state. At step 502, the bridge kernel hardware 110 receives a trigger from the host 102. At step 503, the bridge kernel hardware 110 receives a trigger from the host register interface (e.g., FIG. 3 The bridge core hardware 110 extracts the variable parameters (e.g., variable parameter -1...variable parameter -n) received from the host 102 via the host register interface 300. At step 505, the bridge core hardware 110 temporarily stores the variable parameters (e.g., variable parameter -1...variable parameter -n) received from the host 102 in the handshake area 124 of the DRAM 120. Once the variable parameters are temporarily stored in the DRAM 120, the bridge core hardware 110 sets the "ready" flag 128 in the handshake area 124 of the DRAM 120 at step 507.

[0076] At the stated moment, the bridge kernel hardware 110 waits for the unloaded function in the firmware (e.g., bridge kernel firmware 116) to complete its processing based on variable parameters. For this purpose, at step 509, the bridge kernel hardware 110 polls the "complete" flag 130 in the handshake area 124 of the DRAM 120. In some embodiments, once the bridge kernel hardware 110 detects the "complete" flag 130, it can read any errors or other statuses from the handshake area 124 of the DRAM 120. The bridge kernel hardware 110 updates the register interface 300 (e.g., ...) with the error and / or other statuses 132. FIG. 3 The appropriate register (as shown in the diagram) is then set in the bridge kernel hardware 110. The register of the "completion" flag 130 is then polled by the host application software 134 to indicate the completion of the unload function call.

[0077] At step 511, the bridge core hardware 110 at the host register interface (e.g., FIG. 3 The ready flag is set in the host register interface 300. After step 511, the bridge core hardware 110 returns to step 501.

[0078] FIG. 6 This demonstrates the bridge kernel firmware operation. The bridge kernel firmware can be... FIG. 1A Bridge kernel firmware 116.

[0079] At step 601, the bridge kernel firmware 116 remains in an idle state. At step 603, the bridge kernel firmware 116 polls the "ready" flag 128 in the DRAM 120 by running on the embedded processor 112. In other words, the bridge kernel firmware 116 acts as an offload manager that invokes offloaded functions (e.g., offloaded application functions 114) using appropriate variable arguments. When the bridge kernel firmware 116 detects that the "ready" flag is set, the bridge kernel firmware 116 fetches the variable arguments (e.g., variable argument-1... variable argument-n) temporarily stored in the handshake area 124 of the DRAM 120 at step 605. At step 607, the bridge kernel firmware 116 calls the offloaded application function 114 using the variable arguments of the host 102. The offloaded application function 114 uses the variable arguments (e.g., variable argument-1... variable argument-n) and performs a data processing function as designed. An instance of the offloaded application function 114 is illustrated at instance 608. Once the data processing is complete, the offloaded application function 114 returns the call to the bridge kernel firmware 116 at step 609. At step 611, the bridge kernel firmware 116 sets the "done" flag in the handshake area 124 of the DRAM 120. As described earlier, the "done" flag is in turn polled by the bridge kernel hardware 110 to send the completion back to the host 102. After step 611, the bridge kernel firmware 116 returns to step 601.

[0080] In some embodiments, the bridge kernel acts as a proxy for host applications (e.g., running in user applications 106). For example, host applications (e.g., running in user applications 106) are agnostic of where or how to implement offloaded functions. In some embodiments, the kernel implementation can be transparent to the host 102. In some embodiments, the kernel can be implemented as a software kernel on an embedded processor (e.g., embedded processor 112). However, in some embodiments, the kernel can be implemented in a hardware gate (e.g., bridge kernel hardware 110).

[0081] In some embodiments, the bridge kernel itself can be agnostic to the offloaded functions (e.g., offloaded application functions 114), which can enable user privacy (e.g., IP address privacy). Thus, a user can create their own offloaded functions as a software kernel or hardware kernel without exposing the storage device user. That is, example embodiments of the bridge kernel mechanism can act as a platform that can be used by a user to offload their private acceleration functions to a storage device. In some embodiments, the host interface to the kernel and / or offloaded functions can not change (e.g., the kernel can be upgraded to a high performance version without significant host side changes). In such cases, the bridge kernel (e.g., bridge kernel hardware 110) RTL can provide a standard or agreed interface to the host application (e.g., user application 106).

[0082] In some embodiments, the bridge kernel (e.g., bridge kernel hardware 110) can use FPGA DRAM (e.g., DRAM 120) memory to handshake with the bridge kernel firmware 116. In other embodiments, the bridge kernel hardware 110 can use on-chip FIFOs (e.g., FIFO registers 118) to handshake with the bridge kernel firmware 116. In some embodiments, the RTL of the bridge kernel (e.g., bridge kernel hardware 110) can use FPGA DRAM (e.g., DRAM 120) to pass variable parameters to offloaded functions running on the embedded processor 112.

[0083] In some embodiments, the bridge kernel (e.g., bridge kernel hardware 110) can be agnostic with respect to the underlying transport mechanism (e.g., PCIe, Ethernet, etc.) used to establish a connection between the host 102 and the storage device 104. In some embodiments, a system 100 including a bridge kernel (e.g., bridge kernel hardware 110) can provide relatively fast user engagement by providing relatively fast porting or development options compared to a system without a bridge kernel, increase reuse of existing code bases by users, and can enable a system to perform other activities while developing a high performance kernel. In some embodiments, a system 100 including a bridge kernel (e.g., bridge kernel hardware 110) can also provide system integration, validation, testing, demonstration, etc.

[0084] In some embodiments, the bridge kernel can use variable parameters passed through the host (and / or set by the device) to decide which offloaded function (e.g., kernel) to invoke. In some embodiments, the bridge kernel can invoke a soft kernel, a hard kernel, or one or more kernels of various performance levels. In some embodiments, the bridge kernel can use a cost function to select a particular kernel based on the variable parameters. In some embodiments, the kernel selection is based on configuration parameters such as application type, application identifier, namespace identifier, host identifier, LBA address range, NVM set identifier, NVMe submission queue identifier, completion queue identifier, stream identifier, Ethernet MAC identifier, TCP / IP address, and other transport / network parameters, as well as common parameters such as date and time, etc.

[0085] It is to be understood that the terms “first,” “second,” “third,” and the like, used herein do not connote any hierarchy or order among elements, components, regions, layers, and / or sections. Such terms are used merely as labels to distinguish one element, component, region, layer, or section from another element, component, region, layer, or section. Thus, a first element, component, region, layer, or section discussed herein could be termed a second element, component, region, layer, or section without departing from the spirit and scope of the inventive concept.

[0086] For ease of description, spatial relative terms, such as “under,” “below,” “lower,” “down,” “above,” “upper,” and the like, can be used herein to describe a relationship of one element or feature to another element or feature as illustrated in the figures. It will be understood that such spatial relative terms are intended to encompass different orientations of the device in use or operation, in addition to the orientations depicted in the figures. For example, if a device is turned over, then an element described as “below” or “beneath” other elements or features would then be oriented “above” the other elements or features. Thus, the example terms “below” and “beneath” can encompass both an orientation of above and of below. The device can be otherwise oriented (e.g., rotated 90 degrees or at other orientations) and the spatially relative descriptors used herein interpreted accordingly. In addition, it will also be understood that, when a layer is referred to as being “between” two layers, it can be the only layer between the two layers, or one or more intervening layers can also be present.

[0087] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the inventive concept. As used herein, the terms “substantially,” “approximately,” and similar terms are used as terms of approximation and not as terms of degree, and are intended to account for the inherent deviations in measured or calculated values that would be identified by one of ordinary skill in the art.

[0088] As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and / or "comprising", when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items. Expressions such as "at least one of," when preceding the list of two or more items, cover the case where any one of the items can occur, individually or in combination with any one or more of the other listed items. Additionally, the use of "can", "could", "might", "may", "will", "would", "should", "can", "might", "may", "shall", "will", "would", and "should", when used in the description of the embodiments of the inventive concept, means "one or more embodiments of the disclosure". Furthermore, the term "exemplary" is intended to refer to an example or illustration. As used herein, the terms "use", "using", "used", can be considered synonymous with the terms "utilize", "utilizing", "utilized", respectively.

[0089] It will be understood that when an element or layer is referred to as being "on" another element or layer, "connected to" another element or layer, "coupled to" another element or layer or "adjacent" another element or layer it can be directly on, connected, coupled, or adjacent to the other element or layer or one or more intervening elements or layers can also be present. In contrast, when an element or layer is referred to as being "directly on", "directly connected to", "directly coupled to", or "immediately adjacent" another element or layer, there are no intervening elements or layers present.

[0090] Any numerical range recited herein is intended to include all sub-ranges of the same whole or fractional number of increments as recited. For example, a range of "1.0 to 10.0" is intended to include all sub-ranges, for example, 2.4 to 7.6, of the same whole or fractional number of increments as recited, that is, with a minimum value of equal to or greater than 1.0 and a maximum value of equal to or less than 10.0. Any maximum numerical limitation recited herein is intended to include all lower numerical limitations subsumed therein and any minimum numerical limitation recited in this specification is intended to include all higher numerical limitations subsumed therein.

[0091] In some embodiments, one or more outputs of different embodiments of the methods and systems of the present disclosure can be sent to an electronic device coupled to or having a display device for displaying the one or more outputs or information about the one or more outputs of different embodiments of the methods and systems of the present disclosure.

[0092] The electronic or electrical devices and / or any other related devices or components according to embodiments of the present disclosure described herein can be implemented using any suitable hardware, firmware (e.g., application specific integrated circuit), software, or combination of software, firmware, and hardware. For example, various components of these devices can be formed on one integrated circuit (IC) chip or on separate IC chips. In addition, various components of these devices can be implemented on a flexible printed circuit film, a tape carrier package (TCP), a printed circuit board (PCB), or formed on one substrate. In addition, various components of these devices can be processes or threads running on one or more processors, located in one or more computing devices, executing computer program instructions and interacting with other system components for the purpose of these various functions described herein. The computer program instructions can be stored in memory implemented using any suitable memory device, such as random access memory (RAM), for example. The computer program instructions can also be stored in other non-transitory computer readable media such as a CD-ROM, a flash drive, or the like. Also, those skilled in the art will appreciate that the functionality of various computing devices can be combined or integrated into a single computing device, or the functionality of a particular computing device can be distributed across one or more other computing devices without departing from the spirit and scope of the exemplary embodiments of the present disclosure.

[0093] While exemplary embodiments for a system and method for offloading application functions to a device have been described and shown herein, it will be apparent to those skilled in the art that numerous modifications and variations are possible. It is, therefore, to be understood that within the scope of the principles of the present disclosure, the system and method for offloading application functions to a device can be practiced otherwise than as specifically described herein. The present disclosure is defined by the following claims and their equivalents.

Claims

1. A system for offloading application functions to a device, comprising: Main unit; A storage device including an embedded processor, wherein the embedded processor is configured to perform at least a portion of data processing functions performed by a processor of the host device; as well as A bridge kernel device, comprising bridge kernel hardware and bridge kernel firmware, wherein the bridge kernel device is configured to receive a plurality of variable parameters from the host device and transmit the plurality of variable parameters to the embedded processor for data processing. The plurality of variable parameters are transmitted to an unloaded function that will be executed as a software kernel on the embedded processor, and The bridge kernel firmware uses the plurality of variable parameters to call the offloaded application function in the embedded processor of the storage device for the data processing, and The unloaded application function called by the bridge kernel firmware automatically returns to the bridge kernel firmware based on the completion of the data processing.

2. The system of claim 1, wherein the implementation of the bridge kernel device is transparent to the host device, wherein the bridge kernel device is unknown to the transport mechanism between the host device and the bridge kernel device, wherein the transport mechanism is one of Peripheral Component Interconnection Fast or Ethernet connection.

3. The system according to claim 1, wherein the storage device is a solid-state drive, and the embedded processor is a field-programmable gate array processor, a solid-state drive controller, or a discrete coprocessor, wherein: The embedded processor includes offloaded application functions configured to execute on the embedded processor, and the embedded processor further includes the bridge kernel firmware. The bridge kernel device will transfer the plurality of variable parameters received from the host device to the unloaded application function, and The bridge kernel device extracts the plurality of variable parameters received from the host register interface of the host device.

4. The system of claim 3, wherein the storage device further comprises a first-in-first-out register and a dynamic random access memory, the dynamic random access memory including a plurality of data buffers and a handshake area for storing the plurality of variable parameters received from the host device, and wherein the first-in-first-out register and the dynamic random access memory are communicatively coupled to the bridge core hardware.

5. The system of claim 4, wherein the first-in-first-out register is configured to transfer the plurality of variable parameters to the embedded processor containing the unloaded application function for data processing.

6. The system of claim 4, wherein the bridge kernel hardware is configured to temporarily store the plurality of variable parameters received from the host device into the handshake area of ​​the dynamic random access memory.

7. The system of claim 4, wherein the bridge kernel device is configured to act as a proxy for a host application running on a client application module of the host device, wherein the host application is unaware of where or how the unloaded application functions are implemented.

8. The system of claim 4, wherein the host device includes a client application module and an Open Computing Language module, and wherein the host device is configured to establish a Peripheral Component Interconnect (PCI) or Ethernet connection with the storage device.

9. The system of claim 8, wherein the bridge kernel hardware comprises a plurality of hardware kernels and the bridge kernel firmware comprises a plurality of software kernels, the plurality of software kernels being configured to run on the embedded processor, wherein a host application running on the client application module of the host device is configured to interface with at least one of the plurality of software kernels and the plurality of hardware kernels via the Open Computing Language module.

10. The system of claim 9, wherein the bridge kernel device is configured to select one or more kernels from the plurality of hardware kernels and the plurality of software kernels for data processing based on a cost function.

11. The system of claim 10, wherein the bridge kernel device is configured to select one or more kernels for data processing based on a cost function using storage parameters or networking parameters received from the host device and the plurality of variable parameters received from the host device, wherein the storage parameters or networking parameters received from the host device include at least one of a submission queue identifier, a completion queue identifier, a stream identifier, a host identifier, a logical block address range, a network service identifier, a media access control identifier, a transmission control protocol / internet protocol field, an application type, an application identifier, or a time and date associated with the host device.

12. The system of claim 11, wherein the bridge kernel device is configured to use the first-in-first-out register to select one or more kernels from the plurality of hardware kernels and the plurality of software kernels for data processing.

13. The system of claim 12, wherein the bridge kernel firmware is configured to extract the plurality of variable parameters from the handshake region of the dynamic random access memory and use the plurality of variable parameters received from the host device to invoke the unloaded application function.

14. The system of claim 13, wherein the unloaded application function is configured to use the plurality of variable parameters for data processing.

15. A method for unloading application functions to a device, comprising: The trigger is received from the host device connected to the storage device via the bridge kernel device in the storage device; The bridge kernel device extracts multiple variable parameters received from the host device, wherein the bridge kernel device is configured to extract the multiple variable parameters from the host register interface; The multiple variable parameters are stored in the dynamic random access memory of the storage device through the bridge kernel device, wherein the multiple variable parameters are stored in the handshake area of ​​the dynamic random access memory; The bridge kernel device sets a first ready flag in the dynamic random access memory, wherein the first ready flag is set in the handshake area of ​​the dynamic random access memory. Based on the bridge kernel device, the processing of the unloaded function in the firmware of the bridge kernel device in the embedded processor of the storage device is determined to be complete based on the plurality of variable parameters, and the bridge kernel device polls a completion flag in the dynamic random access memory, wherein the completion flag is polled in the handshake area of ​​the dynamic random access memory, and the embedded processor is configured to perform at least a portion of the data processing functions performed by the processor of the host device. as well as The second ready flag is set in the host register interface by the bridge kernel device; The firmware of the bridge kernel device uses the plurality of variable parameters to call the offloaded application function in the embedded processor of the storage device for data processing; as well as The unloaded application function, based on the completion of the data processing, causes the firmware of the bridge kernel device to return to the firmware of the bridge kernel device. The plurality of variable parameters are transmitted to the unloaded function, which will be executed as a software kernel on the embedded processor.

16. The method of claim 15, further comprising: The bridge kernel device reads errors or statuses from the handshake area of ​​the dynamic random access memory based on detecting the completion flag in the handshake area of ​​the dynamic random access memory. And the error or the status is updated in the host register interface via the bridge kernel device.

17. The method of claim 15, further comprising: The firmware of the bridge kernel device polls the first ready flag in the dynamic random access memory; Multiple variable parameters in the handshake area of ​​the dynamic random access memory are extracted through the firmware of the bridge kernel device; as well as The firmware of the bridge kernel device sets a completion flag in the handshake area of ​​the dynamic random access memory.

18. A system for offloading application functions to a device, comprising: Storage device, including an embedded processor; as well as A bridge kernel device is configured to receive a plurality of variable parameters from a host device and transmit the plurality of variable parameters to the embedded processor for data processing, wherein the embedded processor is configured to perform at least a portion of the data processing functions performed by the processor of the host device. The aforementioned multiple variable parameters are transferred to an unloaded function that will be executed as a software kernel on the embedded processor. The bridge kernel device includes bridge kernel hardware and bridge kernel firmware, and The bridge kernel firmware uses the plurality of variable parameters to call the offloaded application function in the embedded processor of the storage device for the data processing, and The unloaded application function called by the bridge kernel firmware automatically returns to the bridge kernel firmware based on the completion of the data processing.

19. The system of claim 18, wherein the storage device is a solid-state drive, and the embedded processor is a field-programmable gate array processor, a solid-state drive controller, or a discrete coprocessor. The embedded processor includes the unloaded application function and the bridge kernel firmware, and The bridge kernel device transmits the plurality of variable parameters received from the host device to the unloaded application function configured to execute on the embedded processor, wherein the bridge kernel device extracts the plurality of variable parameters received from the host device from the host register interface.

20. The system of claim 19, wherein the storage device further comprises a first-in-first-out (FIFO) register and a dynamic random access memory (DRAM), wherein the DRAM further comprises a plurality of data buffers and a handshake area, wherein the FIFO register and the DRAM are communicatively coupled to the bridge core hardware. The bridge kernel hardware comprises multiple hardware kernels, and the bridge kernel firmware comprises multiple software kernels, the multiple software kernels being configured to run in the embedded processor. The bridge kernel device is configured to select one or more kernels from the plurality of hardware kernels and the plurality of software kernels for data processing based on a cost function using storage or networking parameters received from the host device and the plurality of variable parameters received from the host device. The storage parameters or networking parameters received from the host device are at least one of the following: submission queue identifier, completion queue identifier, stream identifier, host identifier, logical block address range, network service identifier, media access control identifier, transmission control protocol / internet protocol field, application type, application identifier, or time and date associated with the host device. The bridge kernel device is configured to use the first-in-first-out register to select one or more kernels from the plurality of hardware kernels and the plurality of software kernels for data processing.

Images