Storage device and method for processing storage transactions

Abstract

This document discloses storage devices and storage transaction processing methods. Transactions between the storage device and the host computing device are identified. The storage device determines that a transaction meets certain criteria and inserts data into a packet associated with the transaction. The data can be used to identify the memory subsystem of the host computing device. The storage device transmits the packet containing the data to the host computing device for storage in the memory subsystem based on the data.

Description

Storage Device and Storage Transaction Processing Method [Cross - Reference to Related Applications] This application claims priority to and the benefit of U.S. Provisional Patent Application No. 63 / 404,474, filed on September 7, 2022, and entitled "SYSTEM AND METHOD OF INSERTING TPH IN STORAGE TRANSACTIONS OF INTEREST IN A SSD CONTROLLER AGNOSTIC MANNER", the entire disclosure of which is incorporated herein by reference. One or more aspects of embodiments according to this disclosure relate to storage transactions, and more particularly, to reducing access latency of data provided during storage transactions. Data associated with a storage transaction may be stored in different subsystems of a host's memory (such as random access memory (RAM), cache, and similar devices). It may be desirable to efficiently access data associated with a storage transaction. However, the memory subsystem in which the data is stored may affect the access time. The above information disclosed in this background section is only for enhancing the understanding of the background of this disclosure, and thus the above information may include information that does not constitute prior art. One or more embodiments of this disclosure relate to a method for processing storage transactions. The method includes identifying a transaction between a storage device and a host computing device. The storage device determines that the transaction meets a criterion and inserts data into a packet associated with the transaction. The data can be used to identify a memory subsystem of the host computing device. The storage device transmits the packet including the data to the host computing device for storing the packet in the memory subsystem based on the data. According to some embodiments, the transaction may follow a storage interface protocol for transferring packets using direct memory access. According to some embodiments, the storage interface protocol may be a Non - Volatile Memory Express (NVMe) protocol. According to some embodiments, the storage transaction processing method may include performing write address translation based on the data. According to some embodiments, the criterion is the identification of a transaction type. According to some embodiments, the criterion is met in response to identifying the transaction type as a transaction for writing data retrieved from the storage device or for writing data structures related to input / output command completion. According to some embodiments, the criterion may be the identification of parameters associated with a storage device. The parameters may be the status of the storage device or identifiers of components used by the storage device. According to some embodiments, the data may include bits for identifying a memory subsystem. According to some embodiments, the packet may be a transaction layer packet (TLP), and the data may include a transaction layer packet handling hint (TPH) inserted into the header of the transaction layer packet. According to some embodiments, the memory subsystem may include at least a portion of a cache memory. One or more embodiments of the present disclosure are also directed to a storage device including a non-volatile memory device and one or more embedded processors. The one or more embedded processors may each include logic for performing operations of: identifying a transaction with a host computing device; determining that the transaction meets a criterion; inserting data into a packet associated with the transaction, where the data is for identifying a memory subsystem of the host computing device; and transmitting the packet including the data to the host computing device for storing the packet in the memory subsystem based on the data. As those skilled in the art will recognize, embodiments of the present disclosure help reduce access latency of data provided during a storage transaction. These and other features, aspects, and advantages of the embodiments of the present disclosure will be more fully understood when considered in connection with the following detailed description, appended claims, and accompanying drawings. Of course, the actual scope of the invention is defined by the appended claims. Hereinafter, exemplary embodiments will be described in more detail with reference to the accompanying drawings, in which like reference numerals always refer to like elements. However, the present disclosure may be embodied in various different forms and should not be construed as limited to the embodiments shown herein. Rather, these embodiments are provided as examples so that the present disclosure will be thorough and complete and will convey the aspects and features of the present disclosure to those skilled in the art. Accordingly, processes, elements, and techniques not necessary for those skilled in the art to fully understand the aspects and features of the present disclosure may not be described. Unless otherwise indicated, like reference numerals in the drawings and this written description always denote like elements and thus may not be repeated. Additionally, in the figures, the relative sizes of elements, layers, and regions may be exaggerated and / or simplified for clarity. The frequency of use of end-viewable data can be used to store data associated with storage transactions in different types of subsystems of the memory of a host device. For example, frequently accessed data from a storage device can be stored in a portion of the cache memory, while infrequently accessed data can be stored in the main memory (e.g., RAM). The cache memory itself can be organized in a hierarchical manner into different levels or subsystems. For example, a first-level cache can be used to store relatively frequently accessed data, while a second-level cache or a last level cache (LLC) can be used to store relatively less frequently accessed data. One of the factors determining the productivity of the system is the efficiency of retrieving data from a target device (e.g., a storage device). It may be desirable to store the data retrieved from the target device in an appropriate cache level. This can enable better use of the cache memory and reduce system memory accesses that may cause delays in accessing the data. Embodiments of the present disclosure relate to processing storage transactions to reduce access latency of data associated with storage transactions. In this regard, a processor in a storage device monitors storage transactions and inserts a hint or tag into the packets of some of the transactions. The hint can help identify the appropriate host memory subsystem in which the packet is to be stored. The host memory subsystem can be, for example, a cache. The host computing device can use the hint to place the packet into the appropriate memory subsystem. For example, if the packet contains data that may be frequently accessed, the packet can be stored in a memory subsystem with relatively high bandwidth and / or low latency. An application running on the host can quickly access the data in the data packet to generate an output. FIG. 1 is a block diagram of a computer system for processing storage transactions according to an embodiment. The system may include a host computing device (e.g., a host) 100 coupled to a compute storage device (e.g., a storage device) 102 via a wired or wireless storage interface 104 (including Ethernet, Fibre Channel, and / or other storage interfaces). The host 100 can use a storage interface protocol to transact with the storage device 102 via the storage interface 104. The storage interface protocol can be, for example, a non-volatile memory express (NVMe) protocol. The NVMe protocol is used as an example for illustrative purposes of this embodiment. However, those skilled in the art should understand that, without departing from the spirit and scope of the inventive concept, various embodiments will extend to other current or future storage interface protocols that use Peripheral Component Interconnect (PCI) or PCI-Express (PCIe) as the communication link. In one embodiment, the host 100 includes one or more central processing unit (CPU) cores 106 (also simply referred to as "processors"), and the one or more CPU cores 106 are configured to execute computer program instructions and process data stored in the cache memory 108 (also simply referred to as "memory" or "cache"). Hereinafter, the central processing unit core 106 is referred to as the CPU core 106. The cache memory 108 can be dedicated to one of the CPU cores 106 or shared by multiple CPU cores among the CPU cores. The cache memory 108 can include, for example, a level-1 cache coupled to a level-2 cache, and the level-2 cache is coupled to a last-level cache (LLC). The LLC cache can be sequentially coupled to the memory controller 110, and the memory controller 110 is sequentially coupled to the main memory 112. The main memory 112 can include, for example, dynamic random access memory (DRAM), and the DRAM stores computer program instructions and / or data (collectively referred to as data) that can be generated by the storage device 102. In order for the applications of the host 100 to use the data generated by the storage device 102, the data can be loaded into the cache memory 108, and the applications can directly consume the data from the cache memory 108. If the data to be consumed is not yet in the cache, the application may need to query other memory devices in the memory hierarchy to find the data. For example, if the searched data is not in the level-1 cache, the application can query the level-2 cache, and if it is not in the level-2 cache, then query the LLC cache, and if it is not in the LLC cache, then query the DRAM. In one embodiment, the data generated by the storage device 102 can be directly stored in the cache memory 108, thereby bypassing the main memory 112. For example, the data generated by the storage device 102 can be directly stored in the level-2 cache or the LLC cache. Direct cache access mechanisms such as data direct I / O (DDIO) or cache direct memory access (CDMA) can be used to directly write the data into the cache. Using the direct cache access mechanism can help avoid the data access latency typical in DRAM access. In addition, identifying the appropriate cache in which to store the data generated by the storage device 102 can further avoid data access latency while optimizing the use of the limited cache memory space. The storage device 102 can be a solid state drive (SSD) with an embedded processor 120 such as a field programmable gate array (FPGA). In some embodiments, the embedded processor 120 can be a graphics processing unit (GPU), a tensor processing unit (TPU), another application-specific integrated circuit (ASIC), or more general-purpose hardware such as a central processing unit (CPU) configured to execute instructions stored in the storage memory 128. The storage memory 128 can be high-performance memory of the storage device 102 and can include volatile memory and / or non-volatile memory, such as (by way of example) DRAM, synchronous dynamic random access memory (SDRAM), double data rate (DDR) memory, static random access memory (SRAM), but the present disclosure is not limited thereto. The storage memory 128 can be any suitable type of high-performance volatile or non-volatile memory. In some embodiments, the storage memory 128 can be part of the embedded processor 120 and / or the storage controller 124. In some embodiments, the embedded processor 120 can be configured to perform various types of computations and transmit the results of the computations as one or more storage transactions to the host 100. The storage transactions can also be the result of input / output (I / O) requests from an application running on the host computing device 100. The term "storage transaction" generally can be used to refer to an information exchange using a substantially advanced transaction format. For example, the term "storage transaction" can be used to refer to an information exchange via a transaction layer packet (TLP), but the embodiments are not limited thereto. The storage device 102 may further include a host interface 122 and a storage controller 124 coupled to a non-volatile memory (NVM) medium 126. The host interface 122 may include a PCIe port and endpoints that enable ingress communication from the host 100 to the storage device 102 and egress communication from the storage device 102 to the host 100. The NVM medium 126 may include one or more types of non-volatile memory, such as (by way of example) flash memory. The storage controller 124 may be an off-the-shelf storage controller that facilitates the implementation of various embodiments of the present disclosure without modification. The storage controller 124 may be implemented via one or more processors (such as (by way of example) an ASIC) configured to handle storage transactions between the storage device 102 and the host 100. For example, the storage controller 124 may be configured to extract I / O submission requests from one or more submission queues of the host 100, place completion status data in one or more completion queues of the host 100, and write other types of I / O command completion-related data structures (e.g., interrupt data). The storage controller 124 may also be configured to retrieve data requested by the host 100 from the NVM medium 126 in response to a read storage transaction and write the retrieved data into the cache memory 108. The storage controller 124 may further be configured to store data provided by the host 100 into the NVM medium 126 in response to a write storage transaction. In one embodiment, the embedded processor 120 may include logic for monitoring traffic between the host 100 and the storage controller 124 and filtering traffic that meets specific criteria. The logic may be implemented using hardware, firmware (e.g., via an ASIC), and / or by more general-purpose hardware (such as a central processing unit (CPU) configured to execute instructions stored in a non-transitory storage medium (e.g., the storage memory 128)). A hint is inserted into the filtered data packet that meets specific criteria. In one embodiment, the packet is a TLP and the hint is a TLP processing hint (TPH) inserted into the header of the TLP. The packet may include data retrieved from the storage device 102 in response to a read request from the host 100, data related to the completion of an I / O command (e.g., completion queue entries, interrupt data, etc.), or similar data. The host memory controller 110 may use hint data to determine a memory subsystem (e.g., a specific portion of the cache memory 108) in which all packet data or a portion of the packet data (e.g., packet payload data) is to be stored. In one embodiment, the hint data inserted into the packet may be programmed by the CPU core 106. For example, the CPU core 106 may determine the hint data based on the type of storage transaction to improve data retrieval efficiency. Other parameters associated with the storage device 102 and / or the network may also be used to determine the hint data. The parameters may be identifiers of components used by the storage device 102, such as (by way of example) a submission queue identifier (SQID), an NVM set ID, a namespace ID, a partition ID, a channel ID, a host ID, a virtual memory (VM) ID, a container ID, a file ID, an object ID, a key-value (KV) key, and / or a similar ID. In some embodiments, the parameters may be the status or condition of the storage device 102, such as (by way of example) an error status, a full status, a partially full status, and / or a similar status. In some embodiments, different hints may be associated with other parameters such as date, time, device temperature, etc. FIG. 2 is a block diagram of an embedded processor of a compute storage device according to one embodiment. Hereinafter, FIGS. 1 and 2 are referred to together. The embedded processor 120 may include an endpoint 200 for interfacing with the host 100 and a root port 202 for interfacing with the storage controller 124. For example, the endpoint 200 may be a PCIe endpoint. For example, the embedded processor 120 may interface with the host 100 via the endpoint 200 to announce its ability to insert hint data for certain storage transactions. The endpoint 200 may be coupled to asynchronous first-in-first-out (AFIFO) logic 204, 206, which may be configured to transfer data from one clock domain (e.g., the PCIe clock domain) to another clock domain (e.g., the FPGA clock domain). Similarly, the root port 202 may transfer data to and from the storage controller 124 via AFIFO logic 208, 210 coupled to the root port 202. The AFIFO logic 204 to 210 may be implemented using hardware, firmware, or any combination of software, firmware, and / or hardware. In one embodiment, the embedded processor 120 may include a logic block 212 for monitoring traffic between the host 100 (via the host interface 122) and the storage controller 124 and for inserting hint or tag data into packets associated with filtered storage transactions. In this regard, the logic block 212 includes a process module 214, a tag insertion module 216, a read address look-up table (LUT) module 218, and a write address LUT module 220. Although the one or more modules 214 to 220 are assumed to be independent functional units, those skilled in the art will recognize that, without departing from the spirit and scope of the inventive concept, the functions of the modules may be combined or integrated into a single module, or further subdivided into further sub-modules. Additionally, one or more of the modules 214 to 220 may be implemented using hardware, firmware, or any combination of software, firmware, and / or hardware. If implemented using software, the instructions for the functions provided by the one or more modules 214 to 220 may be stored in the storage memory 128. In one embodiment, the process module 214 analyzes requests from the storage controller 124 to the host 100 and response data from the host 100 to the storage controller 124. Requests from the storage controller 124 to the host 100 may include read requests and write requests. Read requests may be used to extract commands or data from the host 100. Write requests may be used to write data retrieved from the NVM media 126 (referred to as command completion data), to write other types of data associated with the completion of I / O commands, and / or similar data. In one embodiment, a read request from the storage controller 124 is provided (e.g., via the process module 214) to the read address LUT module 218 to perform a memory address lookup of the host memory location from which the storage device 102 is reading. The host memory address may be identified from a read address LUT (not shown) (or other memory component). In some embodiments, an arithmetic equation or the like may be used instead of a LUT to determine whether the host memory address falls within a specific address range. Based on the identified memory address, the process module 214 can distinguish the response data fetched from the host memory location as a host command (e.g., a read command or a write command from the submission queue) or host data to be saved to the NVM medium 126. The commands stored in the submission queue of the host 100 can be processed by the process module 214 to extract information from the commands. For example, the process module 214 can extract from the command the completion queue address for writing a completion queue entry when the command is completed, the read address in the main memory 112 from which data is to be read and stored in the NVM medium 126, the write address in the main memory 112 where the completion data is to be written, the address for writing interrupt data, and / or similar addresses. The extracted data can be stored in the read address LUT module 218 or the write address LUT module 220. The addresses stored in the LUT can be used to distinguish packets containing data, completion entries, interrupt data, and similar data. Data packets from the host 100 to be written into the NVM medium 126 (e.g., in response to a write command from the host 100) can pass through the process module 212 without further processing. The write data can be provided to the storage controller 124 via the AFIFO 208 and the root port 202. In one embodiment, the write address LUT module 220 includes logic for performing the following operations: filtering storage transactions from the storage controller 124 for which hint data is to be inserted; and forwarding the data packets of the filtered storage transactions to the tag insertion module 216. Exemplary storage transactions filtered for inserting hint data include transactions for writing completion data to the memory subsystem of the host 100, transactions for writing completion queue entries, transactions for writing interrupt data, and / or other similar transactions for writing data to the memory subsystem of the host 100. In one embodiment, the tag insertion module 216 is configured to insert tag data into the packets of the filtered storage transactions. The tag data can identify the memory subsystem of the host 100 where the packet is to be stored. The tag data can include, for example, the TPH bit field as described in the PCIe Gen 3 standard, such as TPH, PH (processing hint), and ST (steering tag) bits. The tag data can be inserted into, for example, the header of a packet (e.g., a TLP packet). The type of tag inserted into the packet can depend on the type of storage transaction. In one embodiment, the tag insertion module 216 stores a mapping of tag values to associated storage transactions. For example, a first tag value can be associated with a data write transaction, a second tag value can be associated with a completion entry transaction, and a third tag value can be associated with an interrupt entry transaction. In some embodiments, the type of tag inserted into a packet may depend on a parameter associated with storage device 102. The parameter may be an identifier of a component used by storage device 102, such as (by way of example) a submission queue identifier (SQID), an NVM set ID, a namespace ID, a partition ID, a channel ID, a host ID, a VM ID, a container ID, a file ID, an object ID, a KV key, and / or a similar identifier. In some embodiments, the parameter may be a state or condition of storage device 102, such as (by way of example) an error state, a full state, a partially full state, and / or a similar state. In some embodiments, different tag values may be associated with other parameters such as date, time, device temperature, etc. The mapping between storage transactions and tag values may be programmed by host 100. FIG. 3 is a flowchart of a process for processing storage transactions according to one embodiment. Hereinafter, FIGS. 1 and 2 are referred to together. The process begins, and in operation 300, logic block 212 receives storage transaction 300 from storage controller 124 (e.g., via process module 214). The storage transaction may include a request to read a memory location of host 100 or a request to write to a memory location of host 100. The request may conform to a storage interface protocol, such as (by way of example) the NVMe protocol. In operation 302, logic block 212 identifies the transaction type of the storage transaction. In operation 304, logic block 212 determines whether the transaction type meets the criteria for inserting hint data. For example, if the transaction is a write request for a write completion queue entry, completion data, interrupt data, or other similar transaction for writing data to the memory subsystem of host 100 to accelerate access to the written data, the criteria may be met. In this regard, the write address LUT module 220 receives the write request from the storage controller 124 and performs a lookup of the write address associated with the write request from a write address LUT (or other memory component) (not shown) for determining the transaction type. In one embodiment, the write address in the write address LUT module 220 is filled by the process module 214 according to parameters extracted from certain requests (such as (by way of example) read requests) provided by host 100. If the criteria are met, then in operation 306, logic block 212 may insert a hint tag into the packet. The tag insertion module 216 is called to insert the hint tag into the data packet to be written to the write address. The tag may be inserted into the header of the packet. In one embodiment, the data to be written to the write address may be divided into a first set of blocks and a second set of blocks before being provided to host 100. In one embodiment, the tag may be inserted into both the first set of blocks and the second set of blocks. In one embodiment, the tag insertion module 216 selects appropriate tag data to be inserted based on the identified transaction type. The tag data may include, for example, TPH bit fields as set forth in the PCIe Gen 3 standard, such as TPH, PH (processing hint), and ST (steering tag) bits. In one embodiment, the tag insertion module 216 accesses a table having a mapping of tag data to transaction types for identifying the appropriate tag to be inserted into the packet. For example, a transaction for writing completion data may be associated with a first type of tag data for a first memory subsystem, a transaction for writing a completion queue entry may be associated with a second type of tag data for a second memory subsystem (e.g., a specific completion queue), and a transaction for writing interrupt data may be associated with a third type of tag data for a third memory subsystem. In operation 308, the packet with tagged data is provided to the host 100 via the AFIFO 206, the endpoint 200, and the host interface 122. Referring again to operation 304, if the criteria are not met, the write data packet is provided to the host without invoking the tag insertion module 216, and no tag data is inserted into the data packet. FIG. 4 is a flowchart of a process for processing a read request generated by a storage controller according to one embodiment. Hereinafter, FIGS. 1 and 2 are referred to together. The storage controller 124 may issue a read request in response to detecting a command from the host 100 in the submission queue. For example, the storage controller 124 may detect the ringing of a doorbell register that notifies the storage controller 124 that a command has been placed in the submission queue. The storage controller 124 may issue a read request in response to the ringing of the doorbell register to read the command data in the submission queue. In one embodiment, the read address LUT module 218 processes the read request from the storage controller 124. In this regard, in operation 400, the read address LUT module 218 performs a lookup of the read address associated with the read request. The lookup of the read address can be used to determine in operation 402 whether the read storage transaction is for fetching a command or for fetching data. In response to determining that the read storage transaction is for an extract command, the command is retrieved from the submission queue and processed by process module 214. The processing may include, for example, extracting one or more fields from the retrieved command in operation 406. For example, process module 214 may extract a read address, a write address, a submission queue address, a completion queue address, interrupt data, and / or the like. In one embodiment, in operation 408, one or more of the extracted parameters are stored in a read address LUT or a write address LUT. For example, the read address and the submission queue address may be stored in the read address LUT, and the write address, the completion queue address, and the interrupt data may be written to the address LUT. Referring again to block 402, if the read request is to extract data from a read address, then in operation 404 process module 212 ignores the transaction and does not intercept the transaction to extract any parameters. The extracted read data is passed to storage controller 124 via AFIFO 208 and root port 202. FIG. 5 is a flowchart of a process for writing a data packet to a memory subsystem of a host according to one embodiment. Hereinafter, FIGS. 1 and 2 are referred to together. The process begins, and in operation 500, an I / O manager (e.g., memory controller 110) of host 100 receives a packet from storage device 102 via storage interface 104. The data packet may be a modified data packet that includes a tag in the header of the packet. The modified data packet may be storage data retrieved from NVM media 126, an I / O command completion related data structure (e.g., a completion queue entry, interrupt data, etc.), or the like. In operation 502, memory controller 110 extracts the tag from the data packet. In operation 504, memory controller 110 identifies the memory subsystem based on the extracted tag data. For example, memory controller 110 may identify a particular portion of cache memory 108 (e.g., L1 cache, L2 cache, or LLC) in which the data packet is to be written. In operation 506, memory controller 110 writes the packet into the identified memory subsystem. This may help CPU core 106 reduce the time to access the packet and help improve system performance. In some embodiments, writing data packets into the memory subsystem may be performed by the storage controller 124 based on tags in the data packets. In this regard, the storage controller 124 or the embedded processor 120 may maintain an address translation table that can be indexed by the tags. The storage controller 124 may perform write address translation based on the tags. The address translation table may be populated by the host 100, for example, during an initialization phase. The address translation table may identify memory addresses (e.g., write addresses) in different memory subsystems (e.g., different cache levels) into which packets may be written. The storage controller 124 may use the information in the address translation table and the tags to identify the packets and transfer the packets to the appropriate write addresses in the memory subsystem. The storage controller 124 may use a direct cache access mechanism (e.g., DDIO, CDMA, and / or a similar mechanism) to transfer the packets. Regarding the flowcharts of FIGS. 3 to 5, it should be understood that, as recognized by those skilled in the art, the order of the steps of the process is not fixed, but may be modified, reordered, performed differently, sequentially, concurrently, or simultaneously, or changed to any desired order. In some embodiments, the above-described systems and methods for processing storage transactions may be implemented in one or more processors. The term "processor" may refer to one or more processors and / or one or more processing cores. The one or more processors may be hosted in a single device or distributed across multiple devices (e.g., on a cloud system). The processor may include, for example, an application-specific integrated circuit (ASIC), a general-purpose or special-purpose central processing unit (CPU), a digital signal processor (DSP), a graphics processing unit (GPU), and a programmable logic device, such as a field-programmable gate array (FPGA). In a processor as used herein, each function is performed by hardware configured (i.e., hardwired) to perform the function, or by more general hardware (e.g., a CPU) configured to execute instructions stored in a non-transitory storage medium (e.g., memory). The processor may be fabricated on a single printed circuit board (PCB) or distributed across several interconnected PCBs. The processor may include other processing circuitry; for example, the processing circuitry may include two processing circuits, an FPGA, and a CPU interconnected on a PCB. It should be understood that although the terms "first", "second", "third", etc. may be used herein to describe various elements, components, regions, layers, and / or sections, these elements, components, regions, layers, and / or sections should not be limited by these terms. These terms are only used to distinguish one element, component, region, layer, or section from another. Thus, without departing from the spirit and scope of the inventive concept, the first element, first component, first region, first layer, or first section discussed herein may be referred to as the second element, second component, second region, second layer, or second section. The terms used herein are for the purpose of describing particular embodiments only and are not intended to limit the inventive concept. Additionally, unless expressly stated otherwise, the embodiments described herein are not mutually exclusive. Aspects of the embodiments described herein may be combined in some implementations. As used herein, the terms "substantially", "about", and similar terms are used as approximate terms and not as terms of degree, and are intended to account for the inherent deviations of measured or calculated values that would be known to those of ordinary skill in the art. Unless the context clearly dictates otherwise, the singular forms "a" and "an" used herein are also intended to include the plural forms. It should be further understood that when the term "comprises and / or comprising" is used in this specification, it specifies the presence of the stated features, integers, steps, operations, elements, and / or components, but does 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. For example, expressions such as "at least one of..." when appearing after a series of elements modify the entire series of elements and not the individual elements of the series. Additionally, when the term "may" is used in describing embodiments of the inventive concept, it refers to "one or more embodiments of the present disclosure". Further, the term "exemplary" is intended to mean an example or illustration. The terms "use", "using", and "used" as used herein may be considered synonymous with the terms "utilize", "utilizing", and "utilized", respectively. Although exemplary embodiments of systems and methods for processing storage transactions have been specifically described and illustrated herein, many modifications and variations will be apparent to those skilled in the art. Accordingly, it is to be understood that systems and methods for processing storage transactions constructed in accordance with the principles of this disclosure may be implemented differently than specifically described herein. This disclosure is also defined in the following claims and their equivalents. The storage device and the storage transaction processing method may include one or more combinations of the features stated in the following claims. Claim 1: A storage transaction processing method, the method comprising: identifying a transaction between a storage device and a host computing device; determining by the storage device that the transaction meets a criterion; inserting, by the storage device, data into a packet associated with the transaction, wherein the data is used to identify a memory subsystem of the host computing device; and transmitting, by the storage device, the packet including the data to the host computing device for storing the packet in the memory subsystem based on the data. Claim 2: In the method of Claim 1, the transaction follows a storage interface protocol for transferring packets using direct memory access, wherein the storage interface protocol is a Non-Volatile Memory Express (NVMe) protocol. Claim 3: In the method of Claim 1 or 2, perform write address translation based on the data. Claim 4: In the method of any one of Claims 1 to 3, the criterion is the identification of a transaction type. Claim 5: In the method of Claim 4, the criterion is met in response to identifying the transaction type as a transaction for writing data retrieved from the storage device or for writing data structures related to input / output command completion. Claim 6: In the method of any one of Claims 1 to 3, the criterion is the identification of a parameter associated with the storage device. Claim 7: In the method of Claim 6, the parameter is the status of the storage device or an identifier of a component used by the storage device. Claim 8: In the method of any one of Claims 1 to 7, the data includes bits for identifying the memory subsystem. Claim 9: In the method of any one of Claims 1 to 8, the packet is a Transaction Layer Packet (TLP), and the data includes a TLP Processing Hint (TPH) inserted into the header of the TLP. Claim 10: In the method of any one of Claims 1 to 9, the memory subsystem includes at least a portion of a cache memory. Claim 11: A storage device includes: a non-volatile memory device; and one or more embedded processors, wherein the one or more embedded processors respectively include logic for performing the following operations: identifying a transaction with a host computing device; determining that the transaction meets criteria; inserting data into a packet associated with the transaction, wherein the data is used to identify a memory subsystem of the host computing device; and transmitting the packet including the data to the host computing device for storing the packet into the memory subsystem based on the data. Claim 12: In the storage device according to Claim 11, the transaction follows a storage interface protocol for transferring packets using direct memory access. Claim 13: In the storage device according to either Claim 11 or 12, the storage interface protocol is a Non-Volatile Memory Express (NVMe) protocol, and the criteria is the identification of a transaction type. Claim 14: In the storage device according to any one of Claims 11 to 13, the one or more embedded processors include logic for performing write address translation based on the data. Claim 15: In the storage device according to Claim 14, the criteria is met in response to identifying the transaction type as a transaction for writing data retrieved from the storage device or for writing a data structure related to the completion of an input / output command. Claim 16: In the storage device according to any one of Claims 11 to 13, the criteria is the identification of parameters associated with the storage device. Claim 17: In the storage device according to Claim 16, the parameters are the status of the storage device or identifiers of components used by the storage device. Claim 18: In the storage device according to any one of Claims 11 to 17, the data includes bits for identifying the memory subsystem. Claim 19: In the storage device according to any one of Claims 11 to 18, the packet is a Transaction Layer Packet (TLP), and the data includes a TLP Processing Hint (TPH) inserted into the header of the TLP. Claim 20: In the storage device according to any one of Claims 1 to 19, the memory subsystem includes at least a portion of a cache memory. 100: Host / Host Computing Device 102: Storage Device / Computing Storage Device 104: Storage Interface / Wired or Wireless Storage Interface 106: Central Processing Unit (CPU) Core 108: Cache Memory 110: Memory Controller / Host Memory Controller 112: Main Memory 120: Embedded Processor 122: Host Interface 124: Storage Controller 126: Non-Volatile Memory (NVM) Medium 128: Storage Memory 200: Endpoint 202: Root Port 204, 210: AFIFO Logic 206, 208: AFIFO Logic / AFIFO 212: Logic Block 214: Process Module / Module 216: Label Insertion Module / Module 218: Read Address Lookup Table (LUT) Module / Module 220: Write Address LUT Module / Module 300, 302, 304, 306, 308, 400, 402, 404, 406, 408, 500, 502, 504, 506: Actions Non-limiting and non-exhaustive embodiments of the present disclosure are described with reference to the following figures, where like reference numerals throughout the views refer to like components unless otherwise specified. FIG. 1 is a block diagram of a computer system for processing storage transactions according to one embodiment. FIG. 2 is a block diagram of an embedded processor of a computing storage device according to one embodiment. FIG. 3 is a flowchart of a process for processing storage transactions according to one embodiment. FIG. 4 is a flowchart of a process for processing read requests generated by a storage controller according to one embodiment. FIG. 5 is a flowchart of a process for writing data packets to a host's memory subsystem according to one embodiment. 300, 302, 304, 306, 308: Actions

Claims

1. A storage transaction processing method, the storage transaction processing method comprising: Identify transactions between storage devices and mainframe computing devices; The storage device determines that the transaction involves storing the packet to the host computing device; Based on determining that the transaction is for storing the packet, the transaction type of the transaction is determined; based on the determined transaction type, the storage device inserts a value selected from a first value associated with a first transaction type and a second value associated with a second transaction type into the packet, wherein the value corresponds to a location in the memory subsystem of the host computing device; and the storage device transmits the packet with the inserted value to the host computing device for storing the packet in the location in the memory subsystem based on the value.

2. The storage transaction processing method as described in claim 1, wherein the transaction follows a storage interface protocol for transmitting the packet using direct memory access, wherein the storage interface protocol is a Fast Non-Volatile Memory (NVMe) protocol.

3. The storage transaction processing method as described in claim 1 further includes: Write address translation is performed based on the value.

4. The storage transaction processing method as described in claim 1, wherein the packet includes data structure for writing data retrieved from the storage device or for completing input / output commands.

5. The storage transaction processing method as described in claim 1, wherein the value is determined based on parameters associated with the storage device.

6. The storage transaction processing method as described in claim 5, wherein the parameter is the status of the storage device or an identifier of the components used by the storage device.

7. The storage transaction processing method as described in claim 1, wherein the value includes bits for identifying the memory subsystem.

8. The storage transaction processing method as described in claim 1, wherein the packet is a transaction layer packet (TLP) and the value includes a transaction layer packet processing hint (TPH) inserted into the header of the transaction layer packet.

9. The storage transaction processing method as described in claim 1, wherein the memory subsystem includes at least a portion of cache memory.

10. A storage device, comprising: Non-volatile memory devices; And one or more embedded processors, wherein each of the one or more embedded processors includes logic for performing the following operations: identifying a transaction with a host computing device; determining that the transaction is for storing a packet to the host computing device; and, based on determining that the transaction is for storing the packet, inserting a value corresponding to a location in the memory subsystem of the host computing device into the packet; and transmitting the packet containing the inserted value to the host computing device, wherein the host computing device is configured to: retrieve the value inserted in the packet; The location of the memory subsystem is identified based on the value extracted from the packet; and the packet is stored at the location of the memory subsystem.

11. The storage device as claimed in claim 10, wherein the transaction follows a storage interface protocol for transmitting the packet using direct memory access, wherein the storage interface protocol is a Fast Non-Volatile Memory (NVMe) protocol.

12. The storage device as claimed in claim 10, wherein the one or more embedded processors include logic for performing write address translation based on the value.

13. The storage device as claimed in claim 10, wherein the packet includes a data structure for writing data retrieved from the storage device or for completing input / output commands.

14. The storage device as claimed in claim 10, wherein the value is determined based on parameters associated with the storage device.

15. The storage device as claimed in claim 14, wherein the parameter is a condition of the storage device or an identifier of a component used by the storage device.

16. The storage device as claimed in claim 10, wherein the value includes bits for identifying the memory subsystem.

17. The storage device as claimed in claim 10, wherein the packet is a transaction layer packet (TLP), and the value includes a transaction layer packet processing hint (TPH) inserted into the header of the transaction layer packet.

18. The storage device as claimed in claim 10, wherein the memory subsystem includes at least a portion of cache memory.

Images