System and method for processing storage transactions

Abstract

Systems and methods for processing storage transactions are disclosed. A transaction between a storage device and a host computing device is identified. The storage device determines that the transaction satisfies 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 sends the packet including the data to the host computing device to store the packet in the memory subsystem based on the data.

Description

[0001] This application claims priority to and the benefit of U.S. Provisional Patent Application No. 63 / 404,474 filed in the U.S. Patent and Trademark Office on September 7, 2022, and U.S. Patent Application No. 17 / 965,545 filed in the U.S. Patent and Trademark Office on October 13, 2022, the disclosures of which are incorporated by reference herein in their entireties. TECHNICAL FIELD

[0002] One or more aspects of embodiments in accordance with the present disclosure relate to storage transactions, and more specifically, to reducing access latency of data provided during a storage transaction. BACKGROUND

[0003] Data associated with a storage transaction can be stored in different subsystems of a host memory, such as random access memory (RAM), cache, and the like. It can be desirable to efficiently access the data associated with the storage transaction. However, the memory subsystems storing the data can impact access time.

[0004] The above information disclosed in this Background section is only for enhancing the understanding of the background of the present disclosure, and therefore, it can include information that does not constitute prior art. SUMMARY

[0005] One or more embodiments of the present disclosure relate to a method for processing a storage transaction. The method includes identifying a transaction between a storage device and a host computing device. The storage device determines that the transaction satisfies 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 sends the packet including the data to the host computing device to store the packet in the memory subsystem based on the data.

[0006] According to some embodiments, the transaction can comply with a storage interface protocol for transferring the packet using direct memory access.

[0007] According to some embodiments, the storage interface protocol can be a Non-Volatile Memory Express (NVMe) protocol.

[0008] According to some embodiments, the method for processing a storage transaction can include performing a write address translation based on the data.

[0009] According to some embodiments, the criterion is an identification of a transaction type.

[0010] According to some embodiments, the criterion is satisfied in response to identifying a transaction type as a transaction for writing data retrieved from the storage device or for writing a data structure related to an input / output command completion.

[0011] According to some embodiments, the standard may be the identification of parameters associated with the storage device. These parameters may be the state of the storage device or identifiers of components used by the storage device.

[0012] According to some embodiments, the data may include bits used to identify the memory subsystem.

[0013] According to some embodiments, the packet may be a Transaction Layer Packet (TLP), and the data may include a TLP Processing Hint (TPH) inserted into the header of the TLP.

[0014] According to some embodiments, the memory subsystem may include at least a portion of the cache memory.

[0015] One or more embodiments of this disclosure also relate 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: identifying a transaction with a host computing device; determining that the transaction meets a criterion; 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 sending the packet including the data to the host computing device to store the packet in the memory subsystem based on the data.

[0016] As those skilled in the art will recognize, embodiments of this disclosure help reduce access latency to data provided during storage transactions.

[0017] These and other features, aspects, and advantages of the embodiments of this disclosure will be more fully understood when considered in conjunction with the following detailed description, the appended claims, and the accompanying drawings. Of course, the actual scope of the invention is defined by the appended claims. Attached Figure Description

[0018] Non-limiting and non-exhaustive embodiments of this invention are described with reference to the following drawings, wherein, unless otherwise stated, the same reference numerals refer to the same parts throughout the various views.

[0019] Figure 1 This is a block diagram of a computer system for processing storage transactions according to one embodiment;

[0020] Figure 2 This is a block diagram of an embedded processor in a computing storage device according to one embodiment;

[0021] Figure 3 This is a flowchart of a process for processing storage transactions according to one embodiment;

[0022] Figure 4This is a flowchart of a process for processing a read request generated by a storage controller, according to one embodiment; and

[0023] Figure 5 This is a flowchart of a process for writing data packets to a host's memory subsystem, according to one embodiment. Detailed Implementation

[0024] In the following description, exemplary embodiments will be illustrated with reference to the accompanying drawings, wherein the same reference numerals refer to the same elements throughout. However, this disclosure may be embodied in various different forms and should not be construed as being limited to the embodiments shown herein. Rather, these embodiments are provided as examples so that this disclosure will be thorough and complete, and will fully convey the aspects and features of this disclosure to those skilled in the art. Therefore, unnecessary treatments, elements, and techniques may not be described for a full understanding of the aspects and features of this disclosure by those of ordinary skill in the art. Unless otherwise stated, the same reference numerals denote the same elements throughout the drawings and written description, and therefore their descriptions may not be repeated. Furthermore, in the drawings, the relative dimensions of elements, layers, and regions may be exaggerated and / or simplified for clarity.

[0025] Data associated with storage transactions can be stored in different types and subsystems of memory on the host device based on the frequency of data usage. For example, frequently accessed data from the storage device can be stored in a portion of cache memory, while infrequently accessed data can be stored in main memory (e.g., RAM). Cache memory itself can be hierarchically organized into different levels or subsystems. For example, a level 1 cache can be used to store relatively frequently accessed data, while a level 2 cache or last-level cache (LLC) can be used to store relatively infrequently accessed data.

[0026] One factor determining system efficiency 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. Doing so allows the cache memory to be used in a more optimized manner and reduces system memory accesses that could delay access to the data.

[0027] Embodiments of this disclosure relate to processing storage transactions to reduce access latency to data associated with those transactions. In this regard, a processor within the storage device monitors storage transactions and inserts hints or tags into packets for specific transactions. The hints help identify the appropriate host storage subsystem where the packet will be stored. The host storage subsystem may be, for example, a cache. The hints can be used by the host computing device to place the packet into the appropriate storage subsystem. For example, if the packet contains data that is likely to be accessed frequently, it may be stored in a storage subsystem with relatively high bandwidth and / or low latency. Applications running on the host can quickly access the data in the packet to generate output.

[0028] Figure 1 This is a block diagram of a computer system for processing storage transactions according to one embodiment. The system may include a host computing device (e.g., a host) 100, which is coupled to a computing 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 may participate in transactions with the storage device 102 through the storage interface 104 using a storage interface protocol. The storage interface protocol may be, for example, the Non-Volatile Memory Fast (NVMe) protocol. For the purposes of describing this embodiment, the NVMe protocol is used as an example. However, those skilled in the art will understand that various embodiments will be extended to other current or future storage interface protocols using Peripheral Component Interconnect (PCI) or PCI-Fast (PCIe) as communication links without departing from the spirit and scope of the inventive concept.

[0029] In one embodiment, host 100 includes one or more central processing unit (CPU) cores 106 (also simply "processors") configured to execute computer program instructions and process data stored in cache memory 108 (also simply "memory" or "cache"). Hereinafter, central processing unit core 106 is referred to as CPU core 106. Cache memory 108 may be dedicated to one of the CPU cores 106 or shared by various CPU cores within the CPU cores.

[0030] Cache memory 108 may include, for example, a Level 1 cache incorporated into a Level 2 cache, wherein the Level 2 cache is incorporated into a last-level cache (LLC). The LLC cache may be incorporated in turn into memory controller 110, which is incorporated in turn into main memory 112. Main memory 112 may include, for example, dynamic random access memory (DRAM) storing computer program instructions and / or data (collectively referred to as data) that may be generated by storage device 102.

[0031] To enable applications on host 100 to use data generated by storage device 102, the data can be loaded into cache memory 108, and applications can consume the data directly from cache memory 108. If the data to be consumed is not already in the cache, the application may need to query other memory devices in the memory hierarchy to find the data. For example, if the data being sought is not in the L1 cache, the application may query the L2 cache, and if it is not in the L2 cache, it may query the LLC cache, and if it is not in the LLC cache, it may query the DRAM.

[0032] In one embodiment, data generated by storage device 102 can bypass main memory 112 and be stored directly in cache memory 108. For example, data generated by storage device 102 can be stored directly in a L2 cache or LLC cache. Direct cache access mechanisms (such as Direct Data I / O (DDIO) or Cache Direct Memory Access (CDMA)) can be used to write data directly to the cache. The use of direct cache access mechanisms can help avoid the typical data access latency of DRAM access. In addition, identifying the appropriate cache for storing data generated by storage device 102 can further avoid data access latency while optimizing the use of limited cache memory space.

[0033] Storage device 102 may be a solid-state drive (SSD) having an embedded processor 120, such as a field-programmable gate array (FPGA). In some embodiments, the embedded processor 120 may be a graphics processing unit (GPU), a tensor processing unit (TPU), other application-specific integrated circuits (ASICs), or more general-purpose hardware, such as a central processing unit (CPU) configured to execute instructions stored in storage memory 128. Storage memory 128 may be a high-performance memory of storage device 102 and may include volatile and / or non-volatile memory (such as, for example, DRAM, synchronous dynamic random access memory (SDRAM), double data rate (DDR) memory, static random access memory (SRAM)), but this disclosure is not limited thereto. Storage memory 128 may be any suitable type of high-performance volatile or non-volatile memory. In some embodiments, storage memory 128 may be part of embedded processor 120 and / or storage controller 124.

[0034] In some embodiments, the embedded processor 120 may be configured to perform various types of computations and send the results of the computations to the host 100 as one or more store transactions. A store transaction may also be the result of an input / output (I / O) request from an application running on the host computing device 100. The term store transaction is generally used to refer to information exchange using a substantially high-level transaction format. For example, the term store transaction may be used to refer to information exchange via transaction layer packets (TLPs), but embodiments are not limited thereto.

[0035] Storage device 102 may also include a host interface 122 and a storage controller 124 incorporated into non-volatile memory (NVM) media 126. The host interface 122 may include PCIe ports and endpoints for inputs enabling communication from host 100 to storage device 102 and outputs enabling communication from storage device 102 to host 100. NVM media 126 may include one or more types of non-volatile memory (such as, for example, flash memory).

[0036] Storage controller 124 may be an off-the-shelf storage controller that does not require modification and helps implement various embodiments of the present disclosure. Storage controller 124 may be implemented using one or more processors (such as, for example, an ASIC) configured to handle storage transactions between storage device 102 and host 100. For example, storage controller 124 may be configured to retrieve I / O commit requests from one or more commit queues of host 100, place completion status data in one or more completion queues of host 100, and write other types of I / O command completion-related data structures (e.g., interrupt data). Storage controller 124 may also be configured to retrieve data requested by host 100 from NVM media 126 in response to a read storage transaction and write the retrieved data to cache memory 108. Storage controller 124 may also be configured to store data provided by host 100 to NVM media 126 in response to a write storage transaction.

[0037] 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. This logic may be implemented in 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., storage memory 128). A hint is inserted into the filtered data packets that meet the 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 I / O commands (e.g., completion queue entries, interrupt data, etc.), etc.

[0038] The prompt data may be used by the host memory controller 110 to determine all or part of the storage subsystem (e.g., a specific portion of cache memory 108) of the stored packet data (e.g., packet payload data). In one embodiment, the prompt data inserted into the packet is programmable via CPU core 106. For example, CPU core 106 may determine the prompt data based on the type of storage transaction to improve data retrieval efficiency. Other parameters associated with storage device 102 and / or the network may also be used to determine the prompt data. Parameters may be identifiers of components used by storage device 102 (e.g., Submission Queue Identifier (SQID), NVM Collection ID, Namespace ID, Region ID, Channel ID, Host ID, Virtual Memory (VM) ID, Container ID, File ID, Object ID, Key-Value (KV) Key, etc.). In some embodiments, parameters may be the condition or state of storage device 102 (e.g., error condition, full condition, partially full condition, etc.). In some embodiments, different prompts may be associated with other parameters (e.g., date, time, device temperature, etc.).

[0039] Figure 2 This is a block diagram of an embedded processor in a computing storage device according to one embodiment. In the following, Figure 1 and Figure 2 The embedded processor 120 may include an endpoint 200 for interacting with host 100 and a root port 202 for interacting with storage controller 124. For example, endpoint 200 may be a PCIe endpoint. For example, the embedded processor 120 may interact with host 100 via endpoint 200 to notify it that it can insert hint data for a specific storage transaction.

[0040] Endpoint 200 may be incorporated into asynchronous first-in-first-out (AFIFO) logic 204, 206, which can be configured to transfer data from one clock domain (e.g., a PCIe clock domain) to another clock domain (e.g., an FPGA clock domain). Similarly, root port 202 may transfer data to and from memory controller 124 via AFIFO logic 208, 210 connected to root port 202. AFIFO logic 204-210 may be implemented in hardware, firmware, or any combination of software, firmware, and / or hardware.

[0041] In one embodiment, the embedded processor 120 may include a logic block 212 for monitoring traffic between the host 100 (via host interface 122) and the storage controller 124, and for inserting cue or tag data into packets associated with filtered storage transactions. In this regard, the logic block 212 includes a processing module 214, a tag insertion module 216, a read address lookup table (LUT) module 218, and a write address LUT module 220. While one or more modules 214-220 are assumed to be separate functional units, those skilled in the art will recognize that the functionality of the modules may be combined or integrated into a single module, or further subdivided into additional sub-modules, without departing from the spirit and scope of the inventive concept. Furthermore, one or more of modules 214-220 may be implemented in hardware, firmware, or any combination of software, firmware, and / or hardware. If implemented in software, instructions for the functionality provided by one or more modules 214-220 may be stored in the storage memory 128.

[0042] In one embodiment, processing module 214 analyzes requests from storage controller 124 to host 100, and response data from host 100 to storage controller 124. Requests from storage controller 124 to host 100 may include read requests and write requests. Read requests can be used to retrieve commands or data from host 100. Write requests can be used to write data retrieved from NVM media 126 (referred to as command completion data), other types of data associated with the completion of I / O commands, etc.

[0043] In one embodiment, a read request from the storage controller 124 (e.g., via processing module 214) is provided to the read address LUT module 218 to perform a memory address lookup for the host memory location from which the storage device 102 is reading. The host memory address can be identified from the read address LUT (or other memory component). In some embodiments, arithmetic equations or the like can be used instead of the LUT to determine whether the host memory address falls within a certain address range.

[0044] Based on the identified memory address, processing module 214 can identify response data retrieved from the host memory location as a host command (e.g., a read or write command from the submission queue) or host data to be saved to NVM media 126. Commands stored in the submission queue of host 100 can be processed by processing module 214 to extract information from the commands. For example, processing module 214 can extract from the commands the address of the completion queue for writing a completion queue entry upon command completion, the read address of the main memory 112 from which data will be read to be stored in NVM media 126, the write address of the main memory 112 for writing completion data, the address for writing interrupt data, etc. The extracted data can be stored in read address LUT module 218 or write address LUT module 220. The addresses stored in the LUTs can be used to distinguish packets containing data, completion entries, interrupt data, etc.

[0045] Data packets from host 100 that are to be written to NVM media 126 (e.g., in response to a write command from host 100) can pass through processing module 214 without further processing. The written data can be provided to storage controller 124 via AFIFO 208 and root port 202.

[0046] In one embodiment, the write address LUT module 220 includes logic for filtering storage transactions from the storage controller 124 that will insert prompt data and for forwarding packets of the filtered storage transactions to the tag insertion module 216. Examples of filtered storage transactions for insert prompt data include transactions that write completion data to the host 100's memory subsystem, transactions that write completion queue entries, transactions that write interrupt data, and / or other similar transactions that write data to the host 100's memory subsystem.

[0047] In one embodiment, the tag insertion module 216 is configured to insert tag data into packets of a filtered storage transaction. The tag data identifies the memory subsystem of the host 100 where the packet will be stored. The tag data may include, for example, TPH bit fields (such as TPH, PH (Process Hint), and ST (Switch Tag) bits as described by the PCIe Gen 3 standard). The tag data may be inserted into, for example, the header of a packet (e.g., a TLP packet).

[0048] The type of tag inserted into the package may 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 may be associated with a data write transaction, a second tag value may be associated with a completed entry transaction, and a third tag value may be associated with an interrupted entry transaction.

[0049] In some embodiments, the type of tag inserted into the package may depend on parameters associated with storage device 102. Parameters may be identifiers of components used by storage device 102 (such as, for example, commit queue identifier (SQID), NVM collection ID, namespace ID, region ID, channel ID, host ID, VM ID, container ID, file ID, object ID, key-value key, etc.). In some embodiments, parameters may be the condition or state of storage device 102 (such as, for example, error condition, full condition, partially full condition, etc.). 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 ​​is programmable via host 100.

[0050] Figure 3 This is a flowchart of a process for processing storage transactions according to one embodiment. In the following, Figure 1 and Figure 2 They are referenced together. Processing begins, and in action 300, logic block 212 (e.g., via processing module 214) receives storage transaction 300 from storage controller 124. 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. Requests may conform to storage interface protocols (such as, for example, the NVMe protocol).

[0051] In action 302, logic block 212 identifies (ID) the transaction type for the storage transaction.

[0052] In action 304, logic block 212 determines whether the transaction type meets the criteria for inserting prompt data. For example, the criteria are met if the transaction is a write request for writing a completion queue entry, completion data, interrupted data, or other similar transactions for writing data to the host 100's memory subsystem to expedite access to the written data. In this regard, write address LUT module 220 receives the write request from storage controller 124 and performs a lookup of the write address associated with the write request from the write address LUT (or other memory component) to determine the transaction type. In one embodiment, the write address in write address LUT module 220 is populated by processing module 214 based on parameters extracted from certain requests (such as read requests) provided by host 100.

[0053] If the criteria are met, in action 306, logic block 212 may insert a prompt tag into the packet. Tag insertion module 216 is invoked to insert a prompt tag into the data packet to be written to the write address. The tag may be inserted into the packet header. In one embodiment, the data to be written to the write address may be divided into a first block and a second block before being provided to host 100. In one embodiment, the tag may be inserted into both the first block and the second block.

[0054] In one embodiment, the tag insertion module 216 selects the appropriate tag data to be inserted based on the identified transaction type. The tag data may include, for example, the TPH bit field (such as TPH, PH (Process Hint), and ST (Takeaway Tag) bits) as described by the PCIe Gen 3 standard.

[0055] In one embodiment, the tag insertion module 216 accesses a table that maps tag data to transaction types to identify the appropriate tag to be inserted into the package. 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 completion queue entries 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 interruption data may be associated with a third type of tag data for a third memory subsystem.

[0056] In action 308, a packet with tagged data is provided to host 100 via AFIFO 206, endpoint 200 and host interface 122.

[0057] Referring again to action 304, if the standard is not met, the write packet is provided to the host without invoking the tag insertion module 216, and no tag data is inserted into the packet.

[0058] Figure 4 This is a flowchart of a process for processing a read request generated by a storage controller, according to one embodiment. In the following, Figure 1 and Figure 2 This is referenced together. Storage controller 124 may issue a read request in response to detecting a command from host 100 in the commit queue. For example, storage controller 124 may detect a doorbell register ringing, which notifies storage controller 124 that a command has been placed in the commit queue. Storage controller 124 may issue a read request to read command data from the commit queue in response to the doorbell register ringing.

[0059] In one embodiment, the read address LUT module 218 processes read requests from the storage controller 124. In this regard, in action 400, the read address LUT module 218 performs a lookup of the read address associated with the read request. The read address lookup can be used in action 402 to determine whether the read storage transaction is for retrieving a command or for retrieving data.

[0060] In response to determining that a read storage transaction is for obtaining a command, the command is retrieved from the commit queue and processed by processing module 214. The processing may include, for example, extracting one or more fields from the retrieved command in action 406. For example, processing module 214 may extract the read address, write address, commit queue address, completion queue address, interrupted data, etc. In one embodiment, in action 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 commit queue address may be stored in a read address LUT, while the write address, completion queue address, and interrupted data may be written to a write address LUT.

[0061] Referring again to action 402, if the read request is for retrieving data from the read address, then in action 404, the transaction is ignored by processing module 214 and is not intercepted to extract any parameters. The retrieved read data is passed to storage controller 124 via AFIFO 208 and root port 202.

[0062] Figure 5 This is a flowchart of a process for writing data packets to a host's memory subsystem, according to one embodiment. In the following text, Figure 1 and Figure 2 They are referenced together. Processing begins, and in action 500, the I / O manager of host 100 (e.g., memory controller 110) receives packets from storage device 102 via storage interface 104. The data packets may be modified data packets that include tags in the packet header. Modified data packets may be storage data retrieved from NVM media 126, I / O command completion-related data structures (e.g., completion queue entries, interrupt data, etc.), etc.

[0063] In action 502, memory controller 110 retrieves a tag from a data packet.

[0064] In action 504, memory controller 110 identifies the memory subsystem based on the retrieved tag data. For example, memory controller 110 may identify a specific portion of the cache memory 108 (e.g., L1 cache, L2 cache, or LLC) where data packets are written.

[0065] In action 506, memory controller 110 writes the packet to the identified memory subsystem. This helps CPU core 106 reduce the time spent accessing the packet and helps improve system performance.

[0066] In some embodiments, writing data packets to a memory subsystem may be performed by a 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 indexed by 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 during, for example, an initialization phase. The address translation table may identify memory addresses (e.g., write addresses) of different memory subsystems (e.g., different cache levels) to which packets can be written. The storage controller 124 may use the information in the address translation table and the tags to identify packets and deliver them to the appropriate write address in the memory subsystem. The storage controller 124 may use direct cache access mechanisms (e.g., DDIO, CDMA, etc.) to deliver packets.

[0067] against Figures 3-5 The flowchart should be understood, as will be recognized by those skilled in the art, that the order of the processing steps is not fixed, but can be modified, changed in order, performed differently, sequentially, concurrently or simultaneously, or changed to any desired order.

[0068] In some embodiments, the systems and methods for processing storage transactions discussed above 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. One or more processors may be mounted in a single device or distributed across multiple devices (e.g., on a cloud system). Processors may include, for example, application-specific integrated circuits (ASICs), general-purpose or special-purpose central processing units (CPUs), digital signal processors (DSPs), graphics processing units (GPUs), and programmable logic devices (such as field-programmable gate arrays (FPGAs)). In a processor, as used herein, each function is performed by hardware configured to perform that function (i.e., hardwired) or by more general-purpose hardware (such as a CPU) configured to execute instructions stored in a non-transitory storage medium (e.g., memory). Processors may be fabricated on a single printed circuit board (PCB) or distributed across several interconnected PCBs. Processors may include other processing circuitry; for example, processing circuitry may include two processing circuits, an FPGA and a CPU, interconnected on the PCB.

[0069] It will be understood that while the terms “first,” “second,” “third,” etc., may be used herein to describe various elements, components, regions, layers, and / or portions, these elements, components, regions, layers, and / or portions should not be limited by these terms. These terms are used only to distinguish one element, component, region, layer, or portion from another. Therefore, without departing from the spirit and scope of the inventive concept, the first element, component, region, layer, or portion discussed herein may be referred to as the second element, component, region, layer, or portion.

[0070] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the inventive concept. Furthermore, unless explicitly stated otherwise, the embodiments described herein are not mutually exclusive. Aspects of the embodiments described herein can be combined in various implementations.

[0071] As used herein, the terms “substantially,” “about,” and similar terms are used as approximate terms rather than terms of degree, and are intended to take into account the inherent biases in measurements or calculations that would be recognized by one of ordinary skill in the art.

[0072] As used herein, unless the context clearly indicates otherwise, the singular form is intended to include the plural form as well. It will be further understood that the terms “comprising” and / or “including”, when used in this specification, specify the presence of the stated features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. As used herein, the term “and / or” includes any and all combinations of one or more associated listed items. Expressions such as “at least one of…” modify the entire list of elements when preceding it, rather than a single element in the list. Furthermore, in describing embodiments of the inventive concept, the use of “may” means “one or more embodiments of this disclosure.” Additionally, the term “exemplary” is intended to refer to an example or illustration. As used herein, the term “use” may be considered synonymous with the term “utilize.”

[0073] While 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. Therefore, it will be understood that systems and methods for processing storage transactions constructed in accordance with the principles of this disclosure may be embodied in addition to the specific description herein. The disclosure is also limited by the appended claims and their equivalents.

[0074] Systems and methods for handling storage transactions may include one or more combinations of the features set forth in the following statements.

[0075] Statement 1: A method for processing storage transactions, the method comprising the steps of: identifying a transaction between a storage device and a host computing device; determining by the storage device that the transaction meets a criterion; inserting data by the storage device into a packet associated with the transaction, wherein the data is used to identify a memory subsystem of the host computing device; and sending the packet including the data by the storage device to the host computing device to store the packet in the memory subsystem based on the data.

[0076] Statement 2: As described in Statement 1, the transaction conforms to the storage interface protocol for transmitting the packet using direct memory access, and the storage interface protocol is the Non-Volatile Memory Fast (NVMe) protocol.

[0077] Statement 3: As described in Statement 1 or 2, write address translation is performed based on the data.

[0078] Statement 4: As described in any of Statements 1-3, the criterion is the identification of the transaction type.

[0079] Statement 5: As described in Statement 4, the criterion is satisfied in response to identifying a transaction type as a transaction for writing data retrieved from a storage device or for writing input / output commands to complete related data structures.

[0080] Statement 6: As described in any one of Statements 1-3, the criterion is the identification of parameters associated with the storage device.

[0081] Statement 7: As described in Statement 6, the parameter is the state of the storage device or an identifier of a component used by the storage device.

[0082] Statement 8: As described in any one of Statements 1-7, the data includes bits for identifying the memory subsystem.

[0083] Statement 9: As described in any one of Statements 1-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.

[0084] Statement 10: As described in any one of Statements 1-9, the memory subsystem includes at least a portion of the cache memory.

[0085] Statement 11: A storage device includes: a non-volatile memory device; and one or more embedded processors, wherein each of the one or more embedded processors includes logic for: identifying a transaction with a host computing device; determining that the transaction meets a criterion; 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 sending the packet including the data to the host computing device to store the packet in the memory subsystem based on the data.

[0086] Statement 12: As described in Statement 11, the transaction conforms to the storage interface protocol for transmitting the packet using direct memory access.

[0087] Statement 13: For storage devices as described in any one of Statements 11 or 12, the storage interface protocol is the Non-Volatile Memory Fast (NVMe) protocol, and the standard is the identification of transaction types.

[0088] Statement 14: The storage device as described in any one of Statements 11-13, wherein the one or more embedded processors include logic for performing write address translation based on the data.

[0089] Statement 15: The criterion is satisfied in response to recognizing a transaction type as being for writing data retrieved from the storage device or for writing input / output commands to complete related data structures.

[0090] Statement 16: For a storage device as described in any of Statements 11-13, the criterion is the identification of parameters associated with the storage device.

[0091] Statement 17: As described in Statement 16, the parameter is the state of the storage device or an identifier of a component used by the storage device.

[0092] Statement 18: As described in any one of Statements 11-17, the data includes bits for identifying the memory subsystem.

[0093] Statement 19: As described in any one of Statements 11-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.

[0094] Statement 20: As described in any one of Statements 1-19, the memory subsystem includes at least a portion of the cache memory.

Claims

1. A method for processing storage transactions, the method comprising the following steps: Identify transactions between storage devices and host computing devices; The storage device determines that the transaction is for storing the packet in the host computing device; Based on the determination that the transaction is used to store the package, the transaction type for the transaction is determined; Based on a determined transaction type, a value selected by the storage device from a first value associated with a first transaction type and a second value associated with a second transaction type is inserted into the packet, the value corresponding to the location of the host computing device's memory subsystem; as well as The storage device sends the packet, which has the value inserted in the packet, to the host computing device to store the packet in the location of the memory subsystem based on the value.

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

3. The method of claim 1, further comprising the following steps: Perform a write address translation based on the value.

4. The method of claim 1, wherein, The package includes data retrieved from storage devices or data structures related to input / output commands.

5. The method of claim 1, wherein, The value is determined based on parameters associated with the storage device.

6. The method of claim 5, wherein, The parameter is the state of the storage device or an identifier of a component used by the storage device.

7. The method of claim 1, wherein, The value includes bits used to identify the memory subsystem.

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

9. The method of claim 1, wherein, The memory subsystem includes a portion of the cache memory.

10. A storage device, comprising: Non-volatile memory devices; as well as One or more embedded processors, wherein each of the one or more embedded processors includes logic for the following operations: Identify transactions with the host computing device; The transaction is determined to be for storing a packet on a host computing device; Based on the determination that the transaction is for storing the packet, a value corresponding to the location in the host computing device's memory subsystem is inserted into the packet; and The packet having the value inserted in the packet is sent to the host computing device, wherein the host computing device is configured to: Retrieve the value inserted in the package; and Based on the value retrieved from the package, the location of the memory subsystem is identified; and The packet is stored in the location of the memory subsystem.

11. The storage device of claim 10, wherein, The transaction conforms to a storage interface protocol for transmitting the packet using direct memory access, wherein the storage interface protocol is the Non-Volatile Memory Fast NVMe protocol.

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

13. The storage device of claim 10, wherein, The package includes data retrieved from storage devices or data structures related to input / output commands.

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

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

16. The storage device of claim 10, wherein, The value includes bits used to identify the memory subsystem.

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

18. The storage device of claim 10, wherein, The memory subsystem includes a portion of the cache memory.

Images