Patent Description:
In some embodiments, a computational storage device may perform one or more computations on data received from a host. This may enable the host to offload computations to the storage device to reduce a workload on the host. For example, a host may offload tasks such as data compression, database queries, and/or the like, to a computational storage device
The above information disclosed in this Background section is only for enhancement of understanding of the background of the invention and therefore it may contain information that does not constitute prior art.

<CIT> discloses: A method of processing data, comprising determining whether an event triggering processing of data at a storage device occurs, the data being predetermined to be processed at a computing device associated with the storage device; in response to determining that the event occurs, determining available resources of the storage device; and in response to an amount of the available resources exceeding a first predetermined threshold, causing the storage device to process the data and provide the processed data to the computing device.

<CIT> discloses: Devices and techniques for efficient allocation of storage connection resources. An active trigger for a storage device is received when the storage device is in an idle state. A workload that corresponds to the storage device is measured to determine that the workload meets a threshold. Connection parameters, for a connection to the storage device, are negotiated based on the workload in response to receipt of the active trigger and the workload meeting the threshold. The workload is then executed on the storage device via the connection using the connection parameters.

Specific embodiments are defined in the dependent claims.

The figures are not necessarily drawn to scale and elements of similar structures or functions may generally be represented by like reference numerals or portions thereof for illustrative purposes throughout the figures. The figures are only intended to facilitate the description of the various embodiments described herein. The figures do not describe every aspect of the teachings disclosed herein and do not limit the scope of the claims. To prevent the drawings from becoming obscured, not all of the components, connections, and the like may be shown, and not all of the components may have reference numbers. However, patterns of component configurations may be readily apparent from the drawings. The accompanying drawings, together with the specification, illustrate example embodiments of the present disclosure, and, together with the description, serve to explain the principles of the present disclosure.

Near storage computation may involve the use of computational resources at or near a storage device. This may enable a host to offload computations and/or other operations to a storage device so they may be performed on data received at, stored in, and/or sent from, the storage device. Depending on the implementation details, near storage computation may reduce or minimize I/O operations and/or conserve resources such as bus and/or network bandwidth, host memory capacity, host CPU capacity, and/or the like. Near storage computation may also accelerate overall application performance, for example, data transfer rates (e.g., MB/s), database queries per hour (QPH), response times, and/or the like.

However, depending on the implementation details and dynamic system conditions, it may be more efficient to execute a computation at the host rather than near a storage device. For example, a storage device may store data in a compressed state to reduce the amount of storage space used to store a file or other unit of data. If a host compresses data for an application before writing it to a storage device, it may reduce the amount of data transferred over a bus (e.g., increase the bus bandwidth available for other applications), but it may increase the host CPU load and/or memory usage required to store both the compressed and uncompressed versions of the data (e.g., reduce the CPU clock cycles and/or memory available for other applications). Similarly, when the data is read from the storage device, decompressing the data at the host may reduce the amount of data transferred over a bus but increase the host CPU load.

If, however, the host offloads the compression and/or decompression to the storage device, it may increase the amount of data transferred over the bus (e.g., reduce the bus bandwidth available for other applications), but it may reduce the host CPU load (e.g., increase the CPU clock cycles available for other applications).

Thus, deciding whether to perform a computation at a host or near storage may involve tradeoffs between various performance parameters. These parameters may include current loads such as host CPU/memory load, the saturation point of the bus, system priorities, and/or the like. Moreover, one or more of these parameters may be dynamic (e.g., changing over time, possibly even after a host has sent a storage access request with a command instructing the storage device to perform an operation).

A near storage computation scheme in accordance with example embodiments of the disclosure may adaptively determine, at or near a storage device, whether to perform an operation near storage or at a host. For example, a computational storage device may include a near storage monitor (NSM) that may receive system performance information collected by the host and local performance information collected by the storage device. The NSM may use this information to decide whether to perform an operation (e.g., a computation) at the storage device or at the host. Thus, the determination may be delegated to the storage device to enable the storage device to adaptively perform an operation.

Examples of operations may include database operations such as scans, joins, query planning, cost function calculations, and/or the like, compression and/or decompression computations, and/or the like. Examples of system and/or local performance information may include central processing unit (CPU) usage, memory usage, input and/or output (I/O) loads, network traffic loads, and/or the like. Thus, in some embodiments, an NSM may adaptively decide where to perform an operation in a manner that may improve or optimize the overall system performance.

In some cases, an NSM may make a decision based only on local performance information, for example, if some or all of the system performance information is not available.

In some embodiments in accordance with example embodiments of the disclosure, an NSM may decide on a hybrid and/or a dynamic operation. For example, an NSM may enable a host and a storage device to work collaboratively in a hybrid arrangement by splitting one or more operations between the host and the storage device. As another example, an NSM may dynamically change a decision to perform an operation at the storage device, and/or an allocation of work between a host and the storage device, based on one or more changes in the system performance information, the local performance information, or both.

In some embodiments in accordance with example embodiments of the disclosure, a determination by an NSM may also be based on a status received from a host. Any number and/or types of statuses and/or status states may be implemented. For example, in some embodiments, a host may send a status having one of three states. A first state may indicate that a device should perform an operation associated with a request sent by the host regardless of other considerations. This state may be referred to as ALWAYS, or another term may be used to refer to a similar state. A second state may indicate that the device should not perform an operation associated with a request sent by the host regardless of other considerations. This state may be referred to as NEVER, or another term may be used to refer to a similar state. A third state may indicate that the device should adaptively determine whether to perform an operation associated with a request sent by the host based on information available to the device such as local and/or system performance information. This state may be referred to as ADAPT, or another term may be used to refer to a similar state.

<FIG> illustrates an embodiment of a system with adaptive near storage computation in accordance with example embodiments of the disclosure. The system <NUM> illustrated in <FIG> may include a host <NUM> and an adaptive computational storage device <NUM> that may be arranged to communicate through a bus <NUM>. The host <NUM> may include host logic <NUM> configured to implement one or more adaptive features as disclosed herein. The adaptive computational storage device <NUM> may include a storage medium <NUM>, operation logic <NUM>, and NSM logic <NUM>.

In some embodiments, the NSM logic <NUM> may be configured to implement any of the adaptive near storage computation features disclosed herein. For example, the NSM logic <NUM> may collect information on one or more local performance parameters (e.g., performance counters, metrics, and/or the like) of the adaptive computational storage device <NUM> such as the load levels of one or more device queues (e.g., block device queues, Nonvolatile Memory Express (NVMe) queues, and/or the like), available memory resources, available processing resources, and/or the like. The NSM logic <NUM> may use this information to decide whether to perform an operation at the storage device. For example, in some embodiments, the NSM logic <NUM> may use the collected performance information to determine a local score for the storage device. The local score may indicate, for example, how busy the storage device may be. The NSM logic <NUM> may apply the local score as an input to an evaluation function that may implement one or more equations, policies, priorities, and/or the like to decide whether to perform an operation at the storage device.

In some embodiments, the NSM logic <NUM> may also use system performance information received from the host <NUM> as a monitor score argument (e.g., based on environmental conditions) to decide whether to perform an operation at the storage device. For example, the host <NUM> may collect information on one or more performance parameters of the system <NUM> such as the host CPU load, the host memory load, the saturation point of the bus, system priorities, and/or the like. In some embodiments, the host logic <NUM> may use the collected system performance information to determine a monitor score which may be sent to the NSM logic <NUM>, for example in association with a storage access request. The monitor score may indicate, for example, how busy the host and/or other system components may be. In some embodiments, system performance information may include performance information for any one or more components external to the adaptive computational storage device <NUM>.

The NSM logic <NUM> may apply the monitor score as an additional input to an evaluation function. For example, in some embodiments in which the monitor score and local score are implemented as numerical values, an evaluation function may compare one or both of the monitor score and the local score to a threshold. The decision whether to perform an operation associated with a request may depend on whether one or both of the monitor score and the local score exceeds the threshold.

In some embodiments, a monitor score may be implemented on a numerical scale, for example, from <NUM> to <NUM> where <NUM> may indicate not busy (e.g., zero percent capacity), and <NUM> may indicate completely busy (e.g., <NUM> percent capacity). In one example embodiment, a host may be concerned primarily with CPU usage. If the host has a CPU with ten cores, and all ten cores are zero percent busy, the host may set a monitor score to <NUM>. If all ten cores are <NUM> percent busy, the host may set the monitor score to <NUM>. If five of the cores are zero percent busy and five of the cores are <NUM> percent busy, the host may also set the monitor score to <NUM>. In some embodiments, a monitor score may be set on a sliding scale, for example, according to one or more host priorities.

In some embodiments, a monitor score and/or local score may be implemented with one or more weighted components. For example, some applications may be sensitive to memory usage, so a memory load may be weighted more heavily than other performance parameters when determining a monitor or local score for such an application. As another example, in an embodiment with a server having a relatively low number of CPU cores, CPU usage may be most likely to cause a performance bottleneck. Therefore, a CPU load may be weighted more heavily than other performance parameters when determining a monitor or local score for use with such a server.

Any performance parameters used to determine a monitor score and/or local score may be dynamic (e.g., time dependent), environment dependent, technology dependent, and/or the like. Thus, in some embodiments, the host logic <NUM> and/or the NSM logic <NUM> may dynamically change the monitor score and/or local score to track any of these changes. For example, in some situations, a system load may change between the time a host issues a command and the time a storage device executes the command. In some embodiments, the NSM logic <NUM> may implement an evaluation function that may account for dynamic load changes. In some embodiments, an evaluation function may be implemented using any type of analytical functions, heuristics (including AI), and/or the like.

In some embodiments, the host <NUM> and the NSM logic <NUM> may implement one or more hybrid techniques for performing one or more operations at an adaptive computational storage device. For example, rather than the storage device <NUM> performing all or none of an operation, the work may be split between the host <NUM> and the storage device <NUM>, for example, with each performing <NUM> percent of the work (a <NUM>/<NUM> split), subject to the NSM deciding to perform its <NUM> percent. Moreover, the hybrid work split may also be dynamic such that, based on changing system monitor scores and/or local scores, the split may change to, for example, <NUM>/<NUM>.

In some embodiments, a different combination of one or more performance parameters may be used to determine a monitor score and/or local score depending on an application that may be supported by the system <NUM> and/or adaptive computational storage device <NUM>. For example, online analytical processing (OLAP) workloads may be more sensitive to response times (e.g., latencies), and thus, a monitor score and/or local score used for an OLAP application may be based entirely on, or weighted in favor of, system and/or device latencies. As another example, online transaction processing (OLTP) workloads may be more sensitive to bandwidths (e.g., queries/hour), and thus, a monitor score and/or local score used for an OLTP application may be based entirely on, or weighted in favor of, system and/or device bandwidths.

In some embodiments, the NSM logic <NUM> may also use a status received from the host <NUM> as to determine whether to perform an operation at the storage device. For example, a host may send a status having one of three states such as ALWAYS, NEVER, or ADAPT or similar states, or any other numbers and/or types of states as described above. If the status is ALWAYS, the storage device may always perform an operation associated with a request by the host. If the status is NEVER, the storage device may never perform an operation associated with a request. If the status is ADAPT, the decision may be delegated to the NSM logic <NUM> at the storage device. For example, the NSM logic <NUM> may decide whether to perform near storage compression and/or decompression according to a policy based on the current condition of the system that may be provided as a monitor score.

Although the principles are not limited to any specific implementation details, in some example embodiments, a host may communicate a status and/or monitor score to a storage device through one or more optional arguments that may be added to an existing storage read and/or write command. The following are example embodiments of read and write commands that may be used by a host to request file read and write operations, respectively, by a computational storage device having data compression and/or decompression capabilities:.

where fd may indicate a file descriptor, and buffer may indicate the address of a buffer to use for the file operation.

In this example embodiment, the argument STATUS may have one of three valid values: ALWAYS, NEVER, or ADAPT which may be implemented as described above. The argument monitor_score may be implemented, for example, as a numerical value based on one or more (possibly weighted) system performance parameters as described above.

In some embodiments, a command to request a file read and/or write operation by a storage device may provide a return status that may indicate, for example, whether a near storage operation is complete, an error status, and/or the like.

In some embodiments, rather than adapting an existing command to include one or more arguments related to adaptive near storage computation, one or more new standard and/or custom commands may be defined.

In some embodiments, a status, monitor score, and/or the like may be given precedence, priority, greater or complete weight, and/or the like. Such an embodiment may be based on a system configuration in which the host may have access to better overall performance information, and therefore, may be described as "the host knows best. " For example, in some embodiments, the ALWAYS, NEVER, or ADAPT values of the status may be obeyed absolutely by the storage device. In other embodiments, NSM logic may be given precedence, priority, greater or complete weight, and/or the like. For example, a storage device may use the status values and/or monitor score as suggestions or starting points. In yet other embodiments, an intervening component such as a switch located between the host and the storage device may be given precedence, priority, greater or complete weight, and/or the like.

In some embodiments, checking the load of an I/O queue at a storage device may be a beneficial basis for determining a local score because, depending on the details, it may be implemented as a lightweight check that the storage device may be able to implement completely internally. In such an embodiment, an I/O queue may be checked, for example, for the number of read and/or write requests that may be pending as a measure of how busy the storage device is.

In some example embodiments, for a direct attached storage device, any number of the following parameters (e.g., performance counters) may be used by a host and/or an NSM to determine a monitor score or local score: CPU usage; memory usage; pending processes; priorities of pending processes; swap space usage (e.g., a percentage of virtual memory that is currently being used to temporarily store inactive pages from main physical memory); I/O statistics (e.g., block reads per second and/or block writes per second); I/O wait time (e.g., an amount of time a CPU may spend waiting for an I/O operation to complete); network traffic bandwidth used by each process and/or application; and/or the like.

In some example embodiments, for a network attached storage device, any number of the following parameters (e.g., performance counters) may be used by a host and/or an NSM to determine a monitor score or local score: traffic monitors (e.g., IP traffic monitors) that pass over a network; processes running on a specific port; database statistics of one or more local or remote servers; network traffic activity; and/or the like.

In some embodiments, and depending on the implementation details, adaptive near storage computation may improve the overall system performance and/or the total cost of ownership (TCO) for a storage system. For example, in some embodiments, a decision whether to perform an operation at a computational storage device or the host may be made at the host. However, making this decision at the host may involve sending information on local performance parameters from the storage device to the host which may increase bus traffic. In some embodiments, the host may have multiple attached storage devices which may multiply the amount of bus traffic used to send local performance parameters to the host. Thus, the communication channel between the host and the storage devices may form a bottleneck. Moreover, having multiple storage devices may add to the decision making burden on the host. Thus, implementing decision making at one or more storage devices may reduce bus traffic and/or distribute the decision making burden to multiple devices having processing resources.

Referring again to <FIG>, the adaptive computational storage device <NUM> may be implemented with any type of storage device based on any type of storage medium <NUM> including magnetic media, solid state media, optical media, and/or the like. For example, in some embodiments, the adaptive computational storage device <NUM> may be implemented as a solid state drive (SSD) based on not-AND (NAND) flash memory, persistent memory such as cross-gridded nonvolatile memory, memory with bulk resistance change, and/or the like, and/or any combination thereof. The adaptive computational storage device <NUM> may be implemented in any form factor such as <NUM> inch, <NUM> inch, <NUM> inch, M. <NUM>, Enterprise and Data Center SSD Form Factor (EDSFF), NF1, and/or the like, using any connector configuration such as Serial ATA (SATA), Small Computer System Interface (SCSI), Serial Attached SCSI (SAS), U. <NUM>, and/or the like. The adaptive computational storage device <NUM> may be implemented entirely or partially with, and/or used in connection with, a server chassis, server rack, dataroom, datacenter, edge datacenter, mobile edge datacenter, and/or any combinations thereof, and/or the like.

Although the embodiment illustrated in <FIG> is shown with a single host <NUM> and a single adaptive computational storage device <NUM>, any number of hosts <NUM> and/or storage devices <NUM> may be included, as well as one or more switches and/or other components configured to implement a storage system.

The operation logic <NUM> may implement any type of operation that may be performed by a computational storage device including database operations such as scans, joins, query planning, cost function calculations, and/or the like, compression and/or decompression computations, and/or the like.

The host logic <NUM>, the operation logic <NUM>, and/or the NSM logic <NUM> may be implemented with hardware, software, or any combination thereof including combinational logic, sequential logic, one or more timers, counters, registers, state machines, volatile memories such as dynamic random access memory (DRAM) and/or static random access memory (SRAM), nonvolatile memory such as flash memory including NAND flash memory, persistent memory such as cross-gridded nonvolatile memory, memory with bulk resistance change, and/or the like, and/or any combination thereof, complex programmable logic devices (CPLDs), field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), central processing units (CPUs) such as complex instruction set computer (CISC) processors such as x86 processors and/or reduced instruction set computer (RISC) processors such as ARM processors, graphics processing units (GPUs), neural processing units (NPUs), and/or the like, executing instructions stored in any type of memory. In some embodiments, one or more components may be implemented as a system-on-chip (SOC).

Although the host logic <NUM>, the operation logic <NUM>, and/or the NSM logic <NUM> may be illustrated as separate components, in some embodiments one or more of these components may be integrated into single components. Likewise, any of the host logic <NUM>, the operation logic <NUM>, and/or NSM logic <NUM> may be implemented with multiple components. For example, in some embodiments, the NSM logic <NUM> may be distributed between the storage device <NUM> and a switch that may be located between the storage device <NUM> and the host <NUM>.

The bus <NUM> may be implemented with any type of interface and/or protocol including Peripheral Component Interconnect Express (PCIe), Nonvolatile Memory Express (NVMe), NVMe-over-fabric (NVMe-oF), Ethernet, Transmission Control Protocol/Internet Protocol (TCP/IP), remote direct memory access (RDMA), RDMA over Converged Ethernet (ROCE), FibreChannel, InfiniBand, Serial ATA (SATA), Small Computer Systems Interface (SCSI), Serial Attached SCSI (SAS), iWARP, and/or the like, or combination thereof.

The host <NUM> may be implemented with any type of processing apparatus including, for example, one or more CPUs having any number of CPU cores, any type and/or amount of memory including volatile and/or nonvolatile memory, any number and/or type of bus interfaces, user interfaces, network interfaces, and/or the like, running any number and/or type of operating systems. The host <NUM> may be configured, for example, as one or more application servers, storage servers, and/or the like configured to run one or more user applications that may issue storage access requests for the adaptive computational storage device <NUM>.

<FIG> illustrates an example embodiment of an adaptive computational storage device in accordance with example embodiments of the disclosure. The embodiment illustrated in <FIG> may be used, for example, to implement the storage device <NUM> illustrated in <FIG>.

The storage device <NUM> illustrated in <FIG> may include a bus interface <NUM>, a storage device controller <NUM>, and a storage medium <NUM>. The bus interface <NUM> may be implemented with any type of interface and/or protocol for an interconnect, network, and/or the like as described above. The storage device controller <NUM> may include NSM logic <NUM> and operation logic <NUM>, as well as one or more command queues <NUM>. The storage device controller <NUM> may also include one or more additional components that are not illustrated but may perform routine background management operations such as a flash translation layer (FTL), a flash interface, and/or the like that may perform garbage collection (GC), wear leveling, recovery from unsafe shutdowns, and/or the like for an embodiment that may use flash memory as the storage medium <NUM>. In some embodiments, the bus interface <NUM> and storage device controller <NUM> may be implemented with hardware, software, or any combination thereof as described above with respect to the embodiment illustrated in <FIG>.

For purposes of illustrating some principles of the disclosure, some example embodiments may be described in the context of an operation implemented as a compression and/or decompression operation. However, an operation may be implemented as any type of operation that may be performed by a computational storage device.

<FIG> illustrates an example embodiment of a storage read method with near storage decompression in accordance with example embodiments of the disclosure. For purposes of illustration, the embodiment illustrated in <FIG> may be described in the context of the system illustrated in <FIG>. However, the embodiment illustrated in <FIG> may be implemented with any suitable system, apparatus, and/or devices including any of those disclosed herein. For purposes of illustration, the embodiment illustrated in <FIG> may be described in the context of an adaptive computational storage device <NUM> that may be configured to compress and/or decompress data received from and/or sent to the host <NUM>, respectively, but the method may be applied to any other operation that may be performed by a computational storage device.

The method may begin at operation <NUM> at which an NSM logic <NUM> may receive a read request from the host <NUM> including the arguments STATUS and monitor_score. At operation <NUM>, the method may determine the value of the STATUS argument. If the value of STATUS is NEVER, the method may proceed to operation <NUM> at which the adaptive computational storage device <NUM> may retrieve the requested data (e.g., file, block, key-value, and/or the like) and send it to the host <NUM> without decompressing the data. If the value of STATUS is ALWAYS at operation <NUM>, the method may proceed to operation <NUM> at which the adaptive computational storage device <NUM> may retrieve the requested data, decompress the retrieved data, sent it to the host <NUM>.

If the value of STATUS is ADAPT at operation <NUM>, the method may proceed to operation <NUM> at which the NSM logic <NUM> may use collected knowledge of one or more local performance parameters of the adaptive computational storage device <NUM> to determine a local score (indicated as local_score). The method may then proceed to operation <NUM> at which the NSM logic <NUM> may apply the monitor score and local score as inputs to an evaluation function F which, for example, may determine a numerical value based on one or both of the monitor score and the local score. The numerical value determined by the evaluation function F may then be compared to a threshold. If the numerical value determined by the evaluation function F is less than the threshold, the NSM logic <NUM> may decide not to perform the decompression at the storage device <NUM>. Thus, the method may proceed to operation <NUM> (Yes path) at which the adaptive computational storage device <NUM> may retrieve the requested data (e.g., file, block, key-value, and/or the like) and send it to the host <NUM> without decompressing the data.

If the numerical value determined by the evaluation function F is not less than the threshold, the NSM logic <NUM> may decide to perform the decompression at the storage device <NUM>. Thus, the method may proceed to operation <NUM> (No path) at which the adaptive computational storage device <NUM> may retrieve and decompress the requested data and send it to the host <NUM> in decompressed form.

In some embodiments, and in some situations, the status and/or monitor score may not be available. For example, the host may not include the STATUS and/or monitor_score arguments with a read request. In some embodiments, if the status is not available, the NSM logic <NUM> may default to the ADAPT state and proceed through operations <NUM> and <NUM> using the monitor score as described above. In some embodiments, if both the status and monitor score are not available, the NSM logic <NUM> may default to the ADAPT state and proceed through operations <NUM> and <NUM> using only the local score as an input to the evaluation function F. In some embodiments, if the status is available but the monitor score is not available, the NSM logic <NUM> may proceed through any of the three branches of the method illustrated in <FIG> based on the value of STATUS, but using only the local score as an input to the evaluation function F.

In some embodiments, the method illustrated in <FIG> may have access to additional information about performance parameters for one or more additional components. For example, a switch may be located between the host <NUM> and the adaptive computational storage device <NUM>. In some embodiments, the switch may provide an additional performance score that may be included in the evaluation function F. In some embodiments, the switch may intercept and modify a status and/or performance score sent from the host <NUM> to the adaptive computational storage device <NUM>. In some embodiments, a monitor score may be implemented with one portion based on one or more performance parameters for the host <NUM>, and another portion based on one or more performance parameters for the switch. In some embodiments, the NSM logic <NUM> may decide not to perform a decompression at the storage device <NUM> if the switch is busy and the host is not busy.

<FIG> illustrates an example embodiment of a storage write method with near storage compression in accordance with example embodiments of the disclosure. For purposes of illustration, the embodiment illustrated in <FIG> may be described in the context of the system illustrated in <FIG>. However, the embodiment illustrated in <FIG> may be implemented with any suitable system, apparatus, and/or devices including any of those disclosed herein. For purposes of illustration, the embodiment illustrated in <FIG> may be described in the context of an adaptive computational storage device <NUM> that may be configured to compress and/or decompress data received from and/or sent to the host <NUM>, respectively, but the method may be applied to any other operation that may be performed by a computational storage device.

The method may begin at operation <NUM> at which an NSM logic <NUM> may receive a write request from the host <NUM> including the arguments STATUS and monitor_score. At operation <NUM>, the method may determine the value of the STATUS argument. If the value of STATUS is NEVER, the method may proceed to operation <NUM> at which the adaptive computational storage device <NUM> may write the received data (e.g., file, block, key-value, and/or the like) to the storage medium <NUM> without compressing the data. If the value of STATUS is ALWAYS at operation <NUM>, the method may proceed to operation <NUM> at which the adaptive computational storage device <NUM> may compress the received data and write it in compressed form to the storage medium <NUM>.

If the value of STATUS is ADAPT at operation <NUM>, the method may determine if the write data sent from the host <NUM> is already compressed. For example, compressed data may be sent with a header that may include information about how the data was compressed. Thus, at operation <NUM>, the NSM logic <NUM> may examine a header of the data sent by the host <NUM> to determine if the data is already compressed. If the data is already compressed, the method may proceed to operation <NUM> at which the adaptive computational storage device <NUM> may write the received data (e.g., file, block, key-value, and/or the like) to the storage medium <NUM> without performing a compression operation on the data. At operation <NUM>, if the NSM logic <NUM> determines that the received data has not been compressed, the method may proceed to operation <NUM> at which the adaptive computational storage device <NUM> may compress the received data and write it in compressed form to the storage medium <NUM>.

In some embodiments, if the write request illustrated at operation <NUM> is being used, it may indicate that a file is being stored in a compressed format. Thus, in some embodiments, the method illustrated in <FIG> may ensure that all write data received with the write request for a file is stored in compressed form, for example, to avoid one or more problems that may be encountered if a file is stored partially compressed and partially uncompressed.

In some embodiments, and in some situations, the status may not be available. For example, the host may not include the STATUS argument with a write request. In some embodiments, if the status is not available, the NSM logic <NUM> may default to the ADAPT state and proceed to operation <NUM>.

<FIG> illustrates an example embodiment of a method for a host to track a read operation with near storage decompression and a write operation with near storage compression in accordance with example embodiments of the disclosure.

For purposes of illustration, the embodiment illustrated in <FIG> may be described in the context of the system illustrated in <FIG>. However, the embodiment illustrated in <FIG> may be implemented with any suitable system, apparatus, and/or devices including any of those disclosed herein. For purposes of illustration, the embodiment illustrated in <FIG> may be described in the context of an adaptive computational storage device <NUM> that may be configured to compress and/or decompress data received from and/or sent to the host <NUM>, respectively, but the method may be applied to any other operation that may be performed by a computational storage device. In this example embodiment, the method illustrated in <FIG> may be performed, for example, from a point of view of the host <NUM>. As shown in <FIG>, time may progress in a downward direction.

For a read operation, the method may begin at operation <NUM> at which a host <NUM> may send a read command to an adaptive computational storage device <NUM>. In some embodiments, the command may use any type of command convention, for example, a storage read/write command convention for an open source operating system. For example, a read command may have the following format
C_READ (fd, buffer,. , [ADAPT, monitor_score]);
as described above. In this example, the host <NUM> may set the status to ADAPT so the storage device <NUM> may decide whether to perform a decompression operation on the data retrieved from the storage medium <NUM>. The host <NUM> may further provide a monitor score (monitor_score) for the storage device <NUM> to use in deciding whether to perform the decompression operation at the storage device <NUM> or leave it for the host <NUM> to perform.

Because the host <NUM> may not know whether the adaptive computational storage device <NUM> has decided to perform the decompression at the storage device, the read command may be implemented to provide a return status that may indicate whether a near storage decompression operation has been performed. Thus, at operation <NUM>, the adaptive computational storage device <NUM> may provide a return status that may be obtained, for example, as a return value for the read command. In some embodiments, the return value may be implemented as a Boolean value indicating whether the near storage decompression operation is complete (NS_OP_COMPLETE).

At operation <NUM>, the host <NUM> may obtain the return value. If the return value indicates that the adaptive computational storage device <NUM> has performed the decompression operation (Status == NS_OP_COMPLETE), the method may terminate. If, however, the return value indicates that the adaptive computational storage device <NUM> has not performed the decompression operation (Status == NS_OP_NOT_COMPLETE), the host <NUM> may proceed to perform the decompression on the data returned from the storage device <NUM>.

For a write operation, the method may begin at operation <NUM> at which the host <NUM> may send a write command to the adaptive computational storage device <NUM>. As with the read command, the write command may use any type of command convention, for example, a write command may have the following format
C_WRITE (fd, buffer,. , [ALWAYS, monitor_score]);
as described above. In this example, the host <NUM> may set the status to ALWAYS to indicate that the storage device <NUM> must perform a compression operation on the write data before storing it in the storage medium <NUM>.

Because the host <NUM> may not know whether the adaptive computational storage device <NUM> has performed the decompression at the storage device, the write command may be implemented to provide a return status that may indicate whether a near storage compression operation has been performed. Thus, at operation <NUM>, the adaptive computational storage device <NUM> may provide a return status that may be obtained, for example, as a return value for the write command. In some embodiments, the return value may be implemented as a Boolean value indicating whether the near storage compression operation is complete (NS_OP_COMPLETE).

At operation <NUM>, the host <NUM> may obtain the return value. If the return value indicates that the adaptive computational storage device <NUM> has performed the compression operation (Status == NS_OP_COMPLETE), the method may terminate. If, however, the return value indicates that the adaptive computational storage device <NUM> has not performed the compression operation (Status == NS_OP_NOT_COMPLETE), the host <NUM> may perform an error protocol, for example, to retry the write operation, send the write data to a different adaptive computational storage device, and/or the like.

<FIG> illustrates an example embodiment of a method for a host to track a read operation with near storage decompression in accordance with example embodiments of the disclosure.

For purposes of illustration, the embodiment illustrated in <FIG> may be described in the context of the system illustrated in <FIG>. However, the embodiment illustrated in <FIG> may be implemented with any suitable system, apparatus, and/or devices including any of those disclosed herein. For purposes of illustration, the embodiment illustrated in <FIG> may be described in the context of an adaptive computational storage device <NUM> that may be configured to compress and/or decompress data received from and/or sent to the host <NUM>, respectively, but the method may be applied to any other operation that may be performed by a computational storage device. In this example embodiment, the method illustrated in <FIG> may be performed, for example, from a point of view of the host <NUM>.

The method may be initiated by the host <NUM> at operation <NUM>, for example, by sending a read request to an adaptive computational storage device <NUM>. At operation <NUM>, the host <NUM> may send information about one or more system performance parameters to the NSM logic <NUM> at the storage device <NUM>. For example, the information may be in the form of a monitor score. At operation <NUM>, the NSM logic <NUM> may decide whether to perform a decompression operation associated with the read request at the storage device <NUM>. At operation <NUM>, if the NSM logic <NUM> decides not to perform the decompression operation at the storage device <NUM>, the method may proceed to operation <NUM> at which the storage device <NUM> may read the raw (uncompressed) data from the storage medium <NUM>, send it to the host <NUM>, and proceed back to operation <NUM> at which the host <NUM> may perform the decompression operation on the read data. The storage device may return a status value indicating that the decompression operation was not completed at the storage device.

However, at operation <NUM>, if the NSM logic <NUM> decides to perform the decompression operation at the storage device <NUM>, the method may proceed to operation <NUM> at which the storage device <NUM> may perform the decompression operation on the raw data and send the decompressed data to the host <NUM>. The storage device may return a status value indicating that the decompression operation was completed at the storage device.

<FIG> illustrates an example embodiment of a method for a host to track a write operation with near storage decompression in accordance with example embodiments of the disclosure.

The method may be initiated by the host <NUM> at operation <NUM>, for example, by sending a write request to an adaptive computational storage device <NUM>. At operation <NUM>, the host <NUM> may send information about one or more system performance parameters to the NSM logic <NUM> at the storage device <NUM>. For example, the information may be in the form of a monitor score. At operation <NUM>, the NSM logic <NUM> may decide whether to perform a compression operation associated with the write request at the storage device <NUM>.

At operation <NUM>, if the NSM logic <NUM> decides to perform the compression operation at the storage device <NUM>, the method may proceed to operation <NUM> where the storage device may perform the data compression operation and return a status value indicating that the compression operation was completed at the storage device <NUM>. The method may then proceed to operation <NUM> where the storage device <NUM> may write the compressed data in the storage medium <NUM> of the storage device <NUM>.

Referring again to operation <NUM>, if the NSM logic <NUM> decides not to perform the compression operation at the storage device <NUM>, the method may proceed to operation <NUM> at which the NSM logic <NUM> may determine whether the data was already compressed by the host <NUM>. If the NSM logic <NUM> determines that the host <NUM> has not compressed the data, the storage device <NUM> may return a status value indicating that the compression operation was not performed at the storage device <NUM> and proceed to operation <NUM>. In some embodiments, this status may essentially function as an error message indicating that the write data was not compressed by the host <NUM> or the storage device <NUM>. However, if the NSM logic <NUM> determines, at operation <NUM>, that the host <NUM> has already compressed the data, the method may proceed to operation <NUM> where the storage device <NUM> may write the compressed data in the storage medium <NUM> of the storage device <NUM>.

In some embodiments, one or more database operations may be implemented with adaptive near storage computation in accordance with example embodiments of the disclosure. For example, in some embodiments, a host may attempt to offload the calculation of a cost function to an adaptive computational storage device. A cost function may be used by a database optimizer (e.g., running at a host) to create a database query plan. Examples of parameters that may be considered as part of a cost function may include: (<NUM>) a choice of one or more access paths (e.g., determining a way to access a table such as through indexing, performing a full table scan, and/or the like); (<NUM>) a choice of one or more join orders (e.g., determining an order in which pairs of tables may be joined); and/or (<NUM>) a choice of one or more join methods (e.g., determining a type of joint operation such as outer join, inner join, left join, and/or the like). In some embodiments, an adaptive computational storage device may decide whether to perform a cost function calculation and/or make one or more of these choices at the storage device or at the host based, for example, on a local score for the device and/or a monitor score for a system.

In some embodiments, a database optimizer use near storage computation resources (e.g., operation logic <NUM> as shown in <FIG>) and/or an NSM (e.g., NSM logic <NUM> as shown in <FIG>) to implement a cost function for selecting a query plan (e.g., an optimized query plan). For example, in some embodiments, a choice of location to perform a full table scan may be offloaded to an adaptive computational storage device. Thus, an NSM at the storage device may decide at execution time whether to perform a conditional scan at the storage device or at the host. As another example, in some embodiments, a choice of location to perform partial aggregates may be offloaded to an adaptive computational storage device. Thus, an NSM at the storage device may select one or more aggregates at execution time. As a further example, in some embodiments, a choice of one or more join methods may be offloaded to an adaptive computational storage device. Thus, a plan may indicate a near storage broadcast join may be decided at execution time, based, for example, on system and/or device loads, the final size of the table and/or result to be broadcast, and/or the like.

In some embodiments, one or more of the following performance parameters may be used by a cost function to determine one or more operations to be offloaded to an adaptive computational storage device: one or more near storage operational capabilities (e.g., computation speed, memory resource size, and/or the like); bus and/or network capabilities (e.g., latency, bandwidth, bisection width and/or the like); and/or overall query plan complexity. , if a plan is CPU heavy, it may be beneficial to attempt to offload one or more operations to an adaptive computational storage device.

In some embodiments, deciding whether to perform a database operation at a computational storage device may involve one or more tradeoffs between various performance parameters. For example, in an embodiment in which a merchant may query a database to find yellow shirts that may be in inventory, a filter operation may be offloaded and included in a scan operation at a storage device. In such an operation, instead of returning all rows to the host from the scan operation, the filter operation may return only filtered rows including yellow shirts to the host. Thus, network traffic may be reduced because less data may be returned to the host. However, a cost function may implement selectivity based, for example, on the number of items that may satisfy a filter criteria (which may also be referred to as a filter selectivity ratio. ) For example, if the merchant has many types of a different item (e.g., instant coffee) in inventory, it may not be beneficial to offload a filter for coffee types to the storage device because, in some embodiments, the host may have more powerful processing resources than the storage device. Therefore, the ability to use the more powerful processing resources of the host may outweigh the additional network traffic. Thus, in some embodiments, an NSM may implement an evaluation function that may involve making one or more tradeoffs between performance parameters (e.g., by weighting one or more performance parameters).

A host may perform heterogeneous scheduling by taking into consideration computing units and/or other devices with different performance characteristics such as GPUs, compute units in FPGAs, CPUs with different speeds (e.g., in a distributed system), computational storage devices and/or the like. In some embodiments, heterogeneous scheduling may be integrated with adaptive near storage computation in accordance with example embodiments of the disclosure. For example, in some embodiments, a host scheduler may perform heterogeneous scheduling based at least in part on the presence of an NSM when scheduling tasks for CPUs, GPUs, computational storage devices (e.g., using a status such as ALWAYS, NEVER, and/or ADAPT), and/or the like. As a further example, in some embodiments, an NSM may include functionality to implement decisions other than binary decisions that may have only two options. An example of a non-binary decision, an NSM may include functionality to reorder multiple requests it may receive based on one or more conditions of the storage apparatus such as performance parameters, power parameters, priorities, and/or the like. As a further example of integrating heterogeneous scheduling with adaptive near storage computation, a host may determine a monitor score to send to an NSM based at least in part on coordinating heterogeneous scheduling one or more other system components. In some embodiments, this may improve the efficiency of an NSM.

<FIG> illustrates an embodiment of a system having a switch and multiple adaptive computational storage devices in accordance with example embodiments of the disclosure. The embodiment illustrated in <FIG> may include a host <NUM> and multiple storage devices <NUM>. A switch <NUM> may be located between the host <NUM> and the storage devices <NUM> to control the flow of data between the host <NUM> and the storage devices <NUM> over bus segments <NUM>. In some embodiments, the host <NUM>, storage devices <NUM>, and bus segments <NUM> may be implemented in a manner similar to those described above with respect to <FIG>. For example, each of the storage devices <NUM> may include NSM logic <NUM> and operation logic <NUM>.

The switch <NUM> may include NSM logic <NUM> that may implement some or all of the functionality of the NSM logic <NUM> of one or more of the storage devices <NUM>. Additionally, or alternatively, the NSM logic <NUM> at the switch <NUM> may implement additional functionality for managing adaptive near storage computations for one or more of the storage devices <NUM>. For example, in some embodiments, the NSM logic <NUM> at the switch <NUM> may update a status and/or a monitor score from the host <NUM> before sending it to one or more of the storage devices <NUM>. The NSM logic <NUM> may update a status and/or monitor score, for example, by changing the status and/or monitor score based on one or more system performance parameters that may be visible to the switch due to its connection to multiple storage devices <NUM>.

In some embodiments, the NSM logic <NUM> at the switch <NUM> may work collaboratively with the NSM logic <NUM> of one or more of the storage devices <NUM>. In some embodiments, the NSM logic <NUM> at the switch <NUM> may override the NSM logic <NUM> of one or more of the storage devices <NUM>. In some embodiments, one or more actions taken by the NSM logic <NUM> at the switch <NUM> may be transparent to the NSM logic <NUM> of one or more of the storage devices <NUM>. For example, in some embodiments, the NSM logic <NUM> at the switch <NUM> may intercept and change a monitor score from the host <NUM> before sending the changed monitor score to one or more of the storage devices <NUM>, which may process a request associated with the updated score as if the updated score came directly from the host <NUM>.

<FIG> illustrates an embodiment of an adaptive near storage computation method in accordance with example embodiments of the disclosure. The method illustrated in <FIG> may be implemented, for example, using any of the apparatus illustrated in <FIG>, and/or <FIG>. The method may begin at operation <NUM>. At operation <NUM>, the method may receive a request at a storage apparatus. In some embodiments, the request may include a storage access request and/or a request to perform an operation such as a computation. At operation <NUM>, the method may determine local performance information at the storage apparatus. In some embodiments, the local performance information may include CPU usage, memory usage, queue usage, I/O loads, network traffic loads, and/or the like. At operation <NUM>, the method may perform a computation at the storage apparatus based on the request and the local performance information. In some embodiments, the method may further include performing the computation based on system performance information received at the storage apparatus. The method may end at operation <NUM>.

The embodiment illustrated in <FIG>, as well as all of the other embodiments described herein, are example operations and/or components. In some embodiments, some operations and/or components may be omitted and/or other operations and/or components may be included. Moreover, in some embodiments, the temporal and/or spatial order of the operations and/or components may be varied. Although some components and/or operations may be illustrated as individual components, in some embodiments, some components and/or operations shown separately may be integrated into single components and/or operations, and/or some components and/or operations shown as single components and/or operations may be implemented with multiple components and/or operations.

Claim 1:
A method for adaptive near storage computation comprising:
receiving (<NUM>), from a host (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>) of a system (<NUM>), a request at a storage apparatus;
determining (<NUM>) local performance information at the storage apparatus; and
performing (<NUM>) an operation at the storage apparatus based on the request and the local performance information;
receiving system performance information at the storage apparatus, wherein performing the operation at the storage apparatus is further based on the system performance information, wherein the system performance information is information on one or more performance parameters of the system (<NUM>), such as host CPU load, host memory load or system priorities; and
generating updated system performance information by changing the system performance information, wherein performing the operation at the storage apparatus is based on the updated system performance information, and
wherein:
the storage apparatus comprises a switch (<NUM>) and a storage device (<NUM>, <NUM>, <NUM>, <NUM>) of the system (<NUM>);
generating the updated system performance information comprises generating the updated system performance information at the switch (<NUM>);
performing the operation at the storage apparatus comprises performing the operation at the storage device (<NUM>, <NUM>, <NUM>, <NUM>); and
the switch (<NUM>) is located between the host (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>) and the storage device (<NUM>, <NUM>, <NUM>, <NUM>) to control the flow of data between the host and the storage devices over bus segments (<NUM>).