An inline small data transfer method and system based on an NVMe command queue

Abstract

The application discloses an inline small data transmission method and system based on an NVMe command queue, and belongs to the field of electronic digital data processing. The application aims at the problem that the PRP / SGL mechanism in the existing NVMe protocol takes 4KB physical pages as the minimum transmission granularity, leading to bandwidth amplification and redundant direct memory access operation in the small data scene. The submission queue is expanded into a mixed transmission channel of commands and data. When the effective load is less than or equal to a preset threshold, the host side segments the data, constructs an NVMe command containing a combined command type code, and writes the command and the data segment as a continuous 64-byte entry into the submission queue in sequence. The solid state disk controller sequentially reads the submission queue, identifies the inline transmission mode according to the combined command type code, directly extracts the data segment or triggers the direct memory access engine to perform multi-source aggregation transmission. The application eliminates redundant direct memory access transactions, improves the high-speed peripheral component interconnect link bandwidth utilization, and reduces the small data transmission delay.

Description

Technical Field

[0001] This invention relates to the field of electronic digital data processing, and in particular to an inline small data transmission method and system based on NVMe command queues. Background Technology

[0002] The NVMe (Non-Volatile Memory Express) protocol, as the current mainstream interface standard for solid-state drives (SSDs), defines an efficient communication mechanism between the host and the SSD controller. In the standard NVMe protocol, data transmission mainly relies on the PRP (Physical Region Pages) or SGL (Scatter Gather List) mechanism, both of which use 4KB physical pages as the smallest transmission granularity.

[0003] In emerging application scenarios such as in-memory computing devices and key-value storage SSDs, the I / O mode has shifted from traditional large-block data transfer to a "small but dense, direct, non-persistent" mode. Commands issued from the host side (such as SQL query predicates, key-value identifiers, etc.) are typically only tens to hundreds of bytes. However, the existing NVMe protocol's data transfer mechanism is designed with a minimum granularity of 4KB physical pages. Even if the actual effective payload is only 32 bytes or 128 bytes, a complete 4KB physical page must be allocated and filled before being transported to the device via the direct memory access engine. In high-concurrency, small I / O scenarios, these problems are amplified and become a system performance bottleneck.

[0004] Existing technologies, such as the PRP mechanism specified in the NVMe protocol specification, have the following drawbacks in small data scenarios:

[0005] The PRP (Personal Memory Access Point) transfer granularity is severely mismatched with the actual load. The PRP mechanism requires each data transfer to be in 4KB physical page units. When the actual load is only 64 bytes, the host still needs to allocate a 4KB physical page, write 64 bytes of valid data into it (the remaining 3,968 bytes are zero-padding or invalid data), and then use the PRP pointer to inform the SSD controller to initiate a direct memory access read. This means that the high-speed peripheral component interconnect (PCIe) link actually moves 4096 bytes of data, but only 64 bytes are valid, resulting in a bandwidth utilization of only 1.56% and a bandwidth amplification factor as high as 64 times. Even with a 128-byte load, the amplification factor is still 32 times. This granularity mismatch leads to a serious waste of high-speed peripheral component interconnect bandwidth.

[0006] In PRP mode, after the host writes data to a physical page in host memory, it needs to notify the SSD controller via a doorbell register. The SSD controller first retrieves the command from the commit queue, parses the PRP pointer, and then initiates an independent direct memory access (DMI) read operation to move the data page from host memory. This process involves: (a) host-side memory allocation and page alignment; (b) the SSD controller parsing the PRP pointer and establishing a DMI descriptor; and (c) an independent DMI transaction on the PCIe high-speed interconnect link (including transaction layer packet header overhead, flow control credit wait, etc.). For small data sets, the fixed overhead of establishing and executing DMI transactions far exceeds the data transmission time itself, causing latency to be dominated by the fixed overhead of DMI transactions.

[0007] While existing technologies attempt to inline data into commands for transmission, their implementation still requires reserving additional metadata fields in the command structure to describe the layout of the inline data, and the inline capacity is limited by the expansion space of a single command. In scenarios with multiple data segments, additional transmission transactions still need to be initiated, resulting in limited bandwidth savings. Furthermore, existing solutions do not fully utilize the commit queue space, failing to use the commit queue itself as a continuous data channel. Some existing technologies propose modifying the NVMe protocol specification (such as adding new command opcodes or data transmission modes) or modifying the SSD controller hardware (such as adding a dedicated small data direct memory access engine), but these solutions require approval from the NVMe standards committee, firmware rewriting by SSD manufacturers, and full driver layer adaptation, resulting in long implementation cycles, high costs, and difficulty in rapid promotion within the existing ecosystem.

[0008] Each PRP transfer requires the allocation of a 4KB aligned physical page. In high-concurrency scenarios (such as thousands of small commands per second), the host needs to frequently request and release a large number of physical pages, which exacerbates memory fragmentation, increases kernel memory management overhead, and at the same time, these pages pollute the CPU cache, reducing the performance of other applications on the host. Summary of the Invention

[0009] The purpose of this invention is to provide an inline small data transfer method and system based on NVMe command queues, which solves the technical problems of bandwidth amplification, redundant direct memory access operations, high transmission latency, and waste of host-side resources caused by the PRP / SGL mechanism using 4KB physical pages as the minimum transmission granularity in existing NVMe protocols for small data transfer scenarios.

[0010] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows:

[0011] An inline small data transfer method based on NVMe command queues includes:

[0012] Host-side steps:

[0013] The process involves: acquiring the payload to be transmitted; segmenting the payload into segments according to preset data segment size boundaries when the payload's byte length is less than or equal to a preset threshold; calculating the required number of data segments N; constructing an NVMe command; setting a combined command type code in the reserved field of the NVMe command, which indicates the inline transfer mode used by the current command, including at least a basic inline transfer mode and a prefetch descriptor-based inline transfer mode; constructing a prefetch descriptor when the combined command type code indicates a prefetch descriptor-based inline transfer mode; writing the NVMe command, the prefetch descriptor when the combined command type code indicates a prefetch descriptor-based inline transfer mode, and the N segments obtained from the segmentation into consecutive 64-byte entries, sequentially writing them to the position indicated by the current tail pointer of the commit queue and its subsequent slots; performing a write memory barrier operation; updating the tail pointer of the commit queue; and notifying the solid-state drive controller via a write doorbell register.

[0014] Controller-side steps:

[0015] Upon detecting a doorbell register update, 64-byte entries are sequentially read starting from the current head pointer position of the submission queue, and the combined command type code is parsed. If the combined command type code indicates a basic inline transfer mode, the number of data segments N is extracted from the command, and N data segments are read sequentially. If the combined command type code indicates a prefetch descriptor-based inline transfer mode, the next entry is read as the prefetch descriptor. Based on the information in the prefetch descriptor, the direct memory access engine is triggered to perform multi-source aggregation transfer, transmitting the NVMe command, the prefetch descriptor, and the N data segments as a continuous protocol data unit to the aggregation cache inside the controller in one go. After processing the acquired data, a completion entry is written to the completion queue, the submission queue head pointer is updated, and the host is notified via an interrupt.

[0016] Furthermore, the combined command type code is formed by combining two or more reserved bits in the NVMe command, and the different values ​​of the combined command type code correspond to standard NVMe protocol transmission, basic inline transmission mode and inline transmission mode based on prefetch descriptor, respectively.

[0017] Furthermore, the prefetch descriptor is a 64-byte aligned entry that includes the starting slot offset of the inline data in the submission queue, the number of data segments, and a hardware ordering identifier; the starting slot offset is used to indicate the offset position of the first data segment relative to the slot where the prefetch descriptor is located; the hardware ordering identifier is used by the controller to perform sequence consistency verification after the aggregation transmission is completed.

[0018] Furthermore, the multi-source aggregation transfer is triggered by a hardware ordering unit within the controller. The hardware ordering unit maintains an internal counter and issues a multi-source aggregation transfer instruction to the direct memory access engine based on the information in the prefetch descriptor. The instruction contains multiple source addresses and a destination address. The multiple source addresses respectively point to the positions of the NVMe command, the prefetch descriptor, and the N data segments in the commit queue.

[0019] Furthermore, the direct memory access engine internally maintains a virtual address mapping table to map the logical ring slots of the submission queue to contiguous physical memory addresses. When the multiple source addresses are not physically contiguous, the direct memory access engine performs a one-time continuous read according to the virtual address mapping table to ensure the atomicity of the aggregated transfer.

[0020] Furthermore, the preset threshold is dynamically adjusted: the host maintains a historical load statistics module, records the actual effective load length distribution of the most recent M inline transmissions, calculates the average effective load length μ and standard deviation σ, and the threshold update formula is:

[0021]

[0022] Where M is the statistical window size, ranging from 1000 to 10000; μ is the average effective payload length, calculated using the following formula: L i Let be the effective payload length of the i-th inline transmission; σ is the standard deviation, calculated using the formula: ; k is a coefficient, ranging from 2 to 3; Th min The preset minimum threshold; Th max The preset maximum threshold; Th new This is the updated threshold.

[0023] Furthermore, the preset data segment size is dynamically adjusted based on the maximum effective load negotiated by the high-speed peripheral component interconnection link, and the data segment size S satisfies... byte, ,and MPS represents the maximum effective load; the value of k is determined by the host based on the current effective load length L and MPS. Number of data segments required The last segment is padded with zeros to align with S.

[0024] Furthermore, the host maintains a recently used payload hash table, recording the payload fingerprint and the corresponding cyclic redundancy check-32 checksum. The fingerprint is calculated from the payload content using the Jenkins hash function. The hash table adopts a least recently used eviction policy and has a fixed capacity of 1024 entries. Each hash table entry stores the payload fingerprint, checksum, and original payload length L. During retransmission, if both the payload fingerprint and length match, the stored checksum is reused directly; otherwise, the checksum is recalculated and the hash table is updated.

[0025] Furthermore, the host performs a queue space check before writing to the commit queue: the host maintains a locally cached commit queue head pointer. Sum of tail pointers Calculate the number of currently available entries in the submission queue:

[0026]

[0027] Where QD is the submission queue depth; for basic inline transmission mode, if If so, then sending is allowed; for inline transfer mode based on prefetch descriptors, if If the condition is met, then sending is allowed; otherwise, sending is paused, and the commands to be sent are cached in the host software queue.

[0028] Furthermore, a predictive model is introduced on the host side to record the distribution of the number N segments of inline commands within the past W time windows, and to establish a probability distribution. W ranges from 10 to 100, and each time window contains 1000 command transmissions. Before the next transmission, the host obtains the currently available space A and calculates the segment quantiles based on the historical distribution.

[0029]

[0030] in, The number of segments is the 95th percentile; for basic inline transmission mode, the actual number of segments required is... and If the actual number of segments is not specified, then normal transmission will occur; for inline transmission mode based on prefetch descriptors, if the actual number of segments required is not specified, then transmission will proceed normally. and If N does not meet the slot requirements, then the transmission proceeds normally; if N does not meet the slot requirements, then the transmission switches to the PRP / SGL path; if N meets the slot requirements but... If so, the transmission will be delayed.

[0031] Furthermore, when the controller returns a manufacturer-defined error code due to inline data verification failure, the host-side interrupt handler recognizes the error code and performs a retransmission operation: re-executes the inline write process on the original payload, writes it to the current tail pointer position, and treats the previously failed entries as having been consumed.

[0032] Furthermore, the host maintains the historical failure rate for each queue or each namespace. Exponentially weighted moving average smoothing is used, and the definition is... For the failure indication function of the t-th transmission:

[0033]

[0034] The formula for updating the exponentially weighted moving average of the failure rate is:

[0035]

[0036] in, Let be the smoothed failure rate after the t-th transmission; The smoothing failure rate after the previous transmission; α is the smoothing factor, ranging from 0.1 to 0.3; initial value ;when When the threshold is exceeded, the host will roll back all subsequent small data requests for that target to the standard PRP / SGL path until... The value drops below the threshold in the subsequent T transmissions, where T ranges from 1000 to 10000.

[0037] Furthermore, the controller aggregates completed entries in the completion queue:

[0038] The controller maintains an aggregation timer and an aggregation counter. Each time an inline command is completed within the timer window, the command identifier is recorded in the internal aggregation buffer, and the aggregation counter is incremented by 1. When the timer times out or the aggregation buffer is full, the controller encodes the command identifier in the aggregation buffer into a bitmap and writes it into a 16-byte completion entry in the completion queue. The status code field is set to the vendor-defined aggregation completion code, and the lower 16 bits of the result field are stored as a bitmap.

[0039] In addition, this invention also discloses an inline small data transmission system based on NVMe command queues, used to implement the inline small data transmission method based on NVMe command queues as described above, including:

[0040] The host module is used to acquire the payload to be transmitted. When the byte length of the payload is less than or equal to a preset threshold, the payload is segmented according to a preset data segment size boundary, and the required number of data segments N is calculated. An NVMe command is constructed, and a combined command type code is set in the reserved field of the NVMe command. When the combined command type code indicates an inline transfer mode based on a prefetch descriptor, a prefetch descriptor is constructed. The NVMe command, the prefetch descriptor when the combined command type code indicates an inline transfer mode based on a prefetch descriptor, and the N data segments obtained from the segmentation are written as a series of consecutive 64-byte entries to the position indicated by the current tail pointer of the commit queue and its subsequent slots. After performing a write memory barrier operation, the tail pointer of the commit queue is updated, and the solid-state drive controller is notified through the write doorbell register.

[0041] The solid-state drive controller module includes a ring buffer management unit, a hardware ordering unit, and a direct memory access engine;

[0042] The circular buffer management unit is used to detect doorbell register updates and read entries sequentially from the submission queue;

[0043] The hardware ordering unit is used to parse the combined command type code. If the combined command type code indicates a basic inline transfer mode, the number of data segments N is extracted from the command, and N data segments are read sequentially. If the combined command type code indicates an inline transfer mode based on a prefetch descriptor, the next entry is read as a prefetch descriptor, and the direct memory access engine is triggered to perform multi-source aggregation transfer, transmitting the NVMe command, the prefetch descriptor, and the N data segments as a continuous protocol data unit to the aggregation cache inside the controller in one go.

[0044] The solid-state drive controller module is also used to process the data in the aggregated cache, write a completion entry to the completion queue, update the submission queue head pointer, and notify the host via an interrupt.

[0045] Furthermore, the solid-state drive controller module internally maintains a state machine for each submission queue, and the state machine includes an idle state, a command acquisition state, a descriptor acquisition state, and an inline data state.

[0046] Initially in an idle state, it enters the command acquisition state after detecting an update to the doorbell register and reads an entry.

[0047] If the parsed combined command type code indicates a basic inline transmission mode, then switch to inline data state, sequentially read N data segments, and return to idle state when the decrement counter reaches 0.

[0048] If the parsed combined command type code indicates an inline transport mode based on a prefetch descriptor, then the process transitions to the fetch descriptor state and reads the next entry as the prefetch descriptor.

[0049] After parsing the prefetch descriptor, the system transitions to inline data state and triggers the direct memory access engine to perform multi-source aggregation transmission. The NVMe command, the prefetch descriptor, and the N data segments are transmitted as consecutive protocol data units to the aggregation cache. After the transmission is completed, the system automatically returns to the idle state.

[0050] Compared with the prior art, the present invention has the following beneficial effects:

[0051] This invention directly inlines small-load data after the command entry in the submission queue, using the submission queue itself as a data carrying channel, enabling the effective load to be transmitted precisely at the byte level. This fundamentally eliminates the bandwidth amplification phenomenon caused by 4KB page padding in the traditional PRP mechanism, and improves the effective bandwidth utilization of high-speed peripheral component interconnection links.

[0052] This invention obtains data along with commands in a single commit queue read transaction, avoiding the process of the controller initiating an additional independent direct memory access read operation after parsing the command. It eliminates redundant high-speed peripheral component interconnection transactions and their corresponding transaction layer data packet header overhead and flow control credit waiting time, thereby reducing transmission latency in small data scenarios.

[0053] This invention is based entirely on the existing NVMe protocol framework. It only utilizes command reserved fields, standard doorbell registers, and interrupt mechanisms. It does not require modification of the NVMe protocol specification and can be implemented through controller firmware extensions. It is fully compatible with existing drivers, operating systems, and the NVMe ecosystem, has low deployment costs, and can be extended to existing solid-state drives and in-memory computing devices.

[0054] This invention avoids queue congestion caused by sudden inline commands and repeated retransmissions caused by link quality fluctuations through mechanisms such as queue space reservation, prediction model and adaptive switching of failure rate, thereby enhancing the robustness of the system under variable load and complex environment.

[0055] This invention dynamically matches the data segment size with the maximum effective load of the high-speed peripheral component interconnection link, making full use of the single transaction transmission capability. Through incremental verification and reuse, and completion of entry aggregation, it reduces computational overhead and the number of interruptions, optimizing resource utilization on both the host and controller sides. This invention provides an efficient data transmission channel for emerging application scenarios such as in-memory computing devices and key-value storage solid-state drives, reducing the pressure on host-side memory allocation and cache pollution. While maintaining compatibility with the existing ecosystem, it provides performance support for the "small computation, light task" mode of storage systems. Attached Figure Description

[0056] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained from these drawings without creative effort.

[0057] Figure 1 This is the main flowchart of data transmission on the host side of the present invention.

[0058] Figure 2 This is the main flowchart of data transmission on the controller side of the present invention.

[0059] Figure 3 This is the state transition process of the controller-side state machine in this invention.

[0060] Figure 4 This is a schematic diagram of the inline mode SQ memory layout of the present invention. Detailed Implementation

[0061] In the following description, only certain exemplary embodiments are briefly described. As those skilled in the art will recognize, the described embodiments can be modified in various ways without departing from the spirit or scope of the embodiments of the invention. Therefore, the drawings and description are considered to be exemplary in nature and not restrictive.

[0062] The following is in conjunction with the appendix Figures 1-4 The embodiments of the present invention will be described in detail below.

[0063] This invention extends the NVMe commit queue from a simple command queue to a hybrid "command + data" transmission channel. Leveraging the inherent behavior of the commit queue as a contiguous physical area in host memory and the sequential reading of commit queue entries by the SSD controller via a doorbell register trigger, small-load data is split into 64-byte aligned segments and written to subsequent slots in the commit queue immediately after the command entry. This allows the controller to acquire data simultaneously with command reading, thereby eliminating independent direct memory access transactions and 4KB page padding.

[0064] Host-side implementation steps:

[0065] S1. Obtain the payload to be transmitted and determine whether its byte length is less than or equal to a preset threshold. If the condition is met, proceed to the inline transmission path; otherwise, fall back to the standard PRP / SGL transmission path.

[0066] The preset threshold can be dynamically adjusted: The host maintains a historical load statistics module, which records the actual effective load length distribution of the most recent M inline transmissions, calculates the average effective load length μ and standard deviation σ, and the threshold update formula is:

[0067]

[0068] in:

[0069] To determine the window size, the value ranges from 1000 to 10000, with a default value of 2000;

[0070] The payload length of the i-th inline transfer is in bytes;

[0071] The average effective load length is calculated using the following formula: ;

[0072] The standard deviation is calculated using the following formula: ;

[0073] The coefficient is 2 to 3, and its value ranges from 2 to 3. When the effective load length distribution is approximately normally distributed, Covering approximately 95.4% of the samples, It covers approximately 99.7% of the samples;

[0074] The preset minimum threshold is 64 bytes;

[0075] The preset maximum threshold is 4096 bytes;

[0076] The updated threshold is in bytes.

[0077] The goal of dynamic adjustment is to maximize the proportion of applications using inline transmission.

[0078] S2. Divide the payload into segments with 64-byte boundaries and calculate the required number of data segments. If the payload length L is not an integer multiple of 64, the last segment is padded with zeros to make it 64 bytes.

[0079] In some preferred embodiments, the data segment size can be dynamically adjusted based on the maximum effective load negotiated by the high-speed peripheral component interconnect link. Let the data segment size S satisfy... byte, ,and , This is the maximum payload size, in bytes. The number of data segments required is... The last segment is padded with zeros to align with S.

[0080] In practice, the value of k is determined by the host based on the current effective payload length L and Calculation determined: That is, select the maximum data segment size that does not exceed the maximum payload and payload length to minimize the number of data segments N. If ,but , byte.

[0081] The host and controller negotiate S values ​​via vendor-specific log pages defined in the NVMe protocol: During initialization, the host writes a list of supported S values ​​to the log page. The controller reads this list, confirms the supported S values, and replies. If the controller does not support inline transmission or only supports S=64 bytes, the negotiation falls back to 64-byte alignment mode. The vendor-specific log page is identified by 0xC0, and its data format is as follows: bytes 0-1 store the number of S values ​​supported by the host, bytes 2-63 store the list of supported S values ​​in sequence (each S value occupies 2 bytes), and the controller writes the confirmed S value in the response log page.

[0082] S3. Construct a 64-byte NVMe command. Set the following information in the command's reserved fields or vendor-defined fields:

[0083] Combined command type code: Used to indicate the specific inline transmission mode used by the current command. In this embodiment, the 31st and 30th bits of the command double word 12 are used to construct a 2-bit combined command type code. "01" represents the basic inline transmission mode (only inline flag, no prefetch descriptor), "10" represents the prefetch descriptor-based inline transmission mode (used to support more complex batch operations), "11" is reserved, and "00" represents standard NVMe transmission.

[0084] Number of data segments N: Write the lower 8 bits of double word 13.

[0085] Original payload length L: Write double word 14.

[0086] Checksum: The cyclic redundancy check-32 checksum calculated on the original payload is written to a double word 15.

[0087] At the same time, all fields in the command that were originally used to store PRP / SGL pointers were set to zero to prevent the controller from accidentally initiating direct memory access transfers.

[0088] To support incremental checksum retransmission and reuse, the host maintains a recently used payload hash table, recording the payload fingerprint and its corresponding Cyclic Redundancy Check (CR32) checksum. The fingerprint is calculated using a Jenkins hash function on the payload content. The hash table employs a Least Recently Used (LRU) eviction policy and has a fixed capacity of 1024 entries. To prevent hash collisions, in addition to storing the fingerprint and checksum, each hash table entry also stores the original payload length L. A query requires matching both the fingerprint and length; only if both match can the checksum be reused.

[0089] In scenarios with an extremely low probability of hash collisions (where fingerprints and lengths match but payload content differs), this invention accepts the collision probability because the probability of a collision is lower than [a certain value]. In a real system, this is negligible. During retransmission, if both the payload fingerprint and length match, the stored checksum is reused directly without recalculation; if only the fingerprint matches but the length does not, it is considered a miss, the checksum is recalculated, and the hash table is updated.

[0090] S4. For inline transport mode using prefetch descriptors (i.e., combined command type code "10"), the host also needs to construct a prefetch descriptor. This prefetch descriptor is a 64-byte aligned entry, written to the commit queue immediately after the command entry. The prefetch descriptor contains the following information:

[0091] The starting slot offset of inline data in the submission queue (relative to the slot where the current command is located);

[0092] Number of data segments N;

[0093] Hardware sequence identifiers are used by the controller to perform sequence consistency checks after the aggregated transmission is completed.

[0094] The host will treat the NVMe command, along with (when mode is "10") the prefetch descriptor and N data segments as a continuous sequence. A 64-byte entry, or (when mode is "01") the NVMe command and N data segments as a contiguous block. Each 64-byte entry is written sequentially to the position indicated by the current tail pointer of the commit queue and its subsequent slots, according to the ring buffer address calculation rules of the NVMe commit queue.

[0095] Specifically, let the queue base address be... The queue depth is The current tail pointer is For the basic inline transfer mode ("01"), the write address of the kth entry is:

[0096]

[0097] in:

[0098] The base address of the submission queue in the host memory, in bytes;

[0099] The depth of the submission queue, ranging from 2 to 65536, is expressed in terms of the number of entries.

[0100] The current tail pointer indicates the index of the next write position in the queue, with a value ranging from 0 to... ;

[0101] This is the memory address of the k-th entry, in bytes.

[0102] For inline transfer mode ("10") based on prefetch descriptors, the write address of the k-th entry is:

[0103]

[0104] The meanings of each character are the same as above.

[0105] If the entry being written needs to cross the boundary in the queue (i.e.) or Then the write operation is split into two parts: the first from The first entry is written to the end of the queue, and the remaining entries are written from the beginning of the queue a second time. This splitting is standard operation for NVMe ring buffers.

[0106] To ensure the atomicity of cross-boundary writes, the tail pointer is not updated or the doorbell register is not written between two writes until all segment entries have been written and the memory barrier has been executed. Only then is the tail pointer updated and the doorbell register written at once.

[0107] S5. Perform a write memory barrier operation to ensure that all entries are visible to high-speed peripheral component interconnect devices, preventing out-of-order CPU writes from causing the controller to read incomplete data.

[0108] S6. Update the tail pointer of the commit queue. (For basic inline transmission mode) or (For inline transfer mode based on prefetch descriptors), and write the new tail pointer value to the doorbell register of the SSD controller via a memory-mapped I / O write operation, triggering the controller to read the commit queue.

[0109] Solid-state drive controller side implementation steps:

[0110] S7. After the controller detects an update in the doorbell register, it sequentially reads 64-byte entries starting from the current head pointer position of the submission queue. The controller internally maintains the head pointer of each queue, which is automatically incremented after each read.

[0111] S8. Parse the first 64-byte entry read into an NVMe command. Check the combined command type code in the command:

[0112] If it is "00", then it will be processed according to the standard NVMe process: parse the PRP / SGL pointer and initiate a direct memory access read operation to obtain the data;

[0113] If the result is "01", then proceed to the basic inline data extraction process and execute step S9a;

[0114] If the value is "10", then proceed to the inline data extraction process based on the prefetch descriptor and execute steps S9b to S12.

[0115] S9a. For type code "01", the controller directly extracts the number of data segments N from the command and reads N data segments sequentially. After concatenating these data segments, the controller extracts the effective load according to the original length L of the effective load in the command, calculates the cyclic redundancy check-32 checksum and compares it with the checksum in the command. If they match, the effective load is routed to the corresponding processing unit; otherwise, an error is returned.

[0116] S9b For type code "10", the controller reads the next entry as a prefetch descriptor and parses out the starting slot offset of the inline data in the submission queue, the number of data segments N, and the hardware order preservation identifier.

[0117] S10. The hardware ordering unit inside the controller is activated. Based on the information in the prefetch descriptor, this unit issues a multi-source aggregation transfer instruction to the Direct Memory Access Engine (DME), instructing the DME to perform a one-time multi-source aggregation read, transferring the NVMe command, prefetch descriptor, and N data segments as a single, continuous protocol data unit to the aggregation cache inside the controller. The DME maintains a virtual address mapping table to map the logical ring slots of the submission queue to contiguous physical memory addresses. When multiple source addresses are not physically contiguous, the DME performs a one-time continuous read based on the virtual address mapping table to ensure the atomicity of the aggregation transfer.

[0118] S11. After the data is transmitted to the aggregation cache, the hardware ordering unit performs a sequence consistency check on the command and data based on the hardware ordering identifier in the prefetch descriptor. If the check passes, the payload is extracted from the aggregation cache (truncated according to the original payload length L in the command), and a Cyclic Redundancy Check (CRC-32) checksum is calculated and compared with the checksum in the command. If they match, the payload is routed to the corresponding processing unit; if they do not match, the controller writes a completion entry to the completion queue, and sets the status code field to the vendor-defined error code 0x7F.

[0119] S12. After processing, the controller writes a completion entry to the completion queue (status code 0x00 for success, 0x7F for failure) and updates the submission queue head pointer. (For basic inline transmission mode) or (For inline transfer mode based on prefetch descriptors), and notify the host via an interrupt. The interrupt handler on the host reads the completion queue, updates the locally maintained head pointer, and calls back to the upper-layer application.

[0120] The controller internally maintains a state machine for each submission queue, including four states: idle, command retrieval, descriptor retrieval, and inline data. It initially enters the idle state. Upon detecting a doorbell register update, it enters the command retrieval state and reads an entry. Parsing the combined command type code:

[0121] If the value is "00", the standard NVMe processing flow is entered (the state machine returns to the idle state).

[0122] If the value is "01", switch to inline data mode and set the decrementing counter. Then, N data segments are read sequentially. When the decrement counter C is reduced to 0, the state machine automatically returns to the idle state.

[0123] If the value is "10", the system transitions to the fetch descriptor state, reads the next entry as the prefetch descriptor, parses the prefetch descriptor, transitions to the inline data state, and triggers the direct memory access engine to perform multi-source aggregation transfer. After the transfer is completed, the system automatically returns to the idle state.

[0124] Queue space management and exception recovery: Before step S4, the host can perform a queue space check: The host maintains the locally cached commit queue head pointer. Sum of tail pointers ,in Update based on the completion entries returned by the controller. Update based on commands sent from the host. Calculate the current number of available entries in the submission queue:

[0125]

[0126] in:

[0127] This is the head pointer of the commit queue cached on the host side, with a value ranging from 0 to... ;

[0128] This is the tail pointer of the commit queue cached on the host side, with a value ranging from 0 to... ;

[0129] The depth of the submission queue, expressed in the number of entries;

[0130] The number of currently available queue entries, ranging from 0 to [value missing]. .

[0131] The result of the modulo operation is guaranteed to be between 0 and 1. Within the range.

[0132] For the basic inline transmission mode (“01”), if If yes, then sending is allowed; if no If the command is not sent, the sending process is paused, and the command to be sent is cached in the host software queue, waiting for the controller to update the queue. Send the file after freeing up space.

[0133] For inline transport mode based on prefetch descriptors (“10”), if If yes, then sending is allowed; if no If the command is not sent, the sending process is paused, and the command to be sent is cached in the host software queue, waiting for the controller to update the queue. Send the file after freeing up space.

[0134] To optimize queue space utilization, a predictive model is introduced on the host side to record the distribution of the number N segments of inline commands within the past W time windows, and to establish a probability distribution. W ranges from 10 to 100, with each time window containing 1000 command transmissions; the default W=20. Before the next transmission, the host obtains the currently available space A (i.e., Available) and calculates the segment quantile based on the historical distribution.

[0135]

[0136] in:

[0137] The number of data segments for the inline command;

[0138] The cumulative probability is the number of segments not exceeding n.

[0139] The 95th percentile segment number indicates that 95% of historical commands have no more than this segment number.

[0140] If the actual number of segments required Meets the slot requirements for the corresponding mode (basic inline transmission mode:) Inline transport mode based on prefetch descriptors: )and If it is, then it will be sent normally; if it is... If the slot requirements are not met, there is insufficient space, and the system will switch directly to the PRP / SGL path; if Meets slot requirements but If so, the transmission will be delayed and the prediction model will be updated.

[0141] When the controller returns a manufacturer-defined error code 0x7F due to inline data verification failure, the host-side interrupt handler recognizes this error code and performs a retransmission operation: steps S1 to S6 are re-executed on the original payload, written to the current tail pointer position, and the original failed data is retransmitted. or Each entry is considered consumed by the controller (the controller has already written the failed completion entry to the completion queue and updated the head pointer), requiring no additional cleanup. The retransmission mechanism ensures that the data is eventually transmitted correctly.

[0142] For multi-queue systems, the host can choose to submit inline commands to one or more dedicated "inline queues," isolating them from queues for regular commands. The host negotiates the number and depth of inline queues with the controller using a vendor-defined field in the NVMe Identify Controller data structure. During initialization, the controller allocates dedicated resources to these queues to avoid resource contention that may arise when inline commands are mixed with regular commands.

[0143] The host also maintains the historical failure rate for each queue or each namespace. Exponentially weighted moving average smoothing is used. Definition For the failure indication function of the t-th transmission:

[0144]

[0145] The formula for updating the exponentially weighted moving average of the failure rate is:

[0146]

[0147] in:

[0148] is the smooth failure rate after the t-th transmission, with a value ranging from 0 to 1;

[0149] This represents the smoothed failure rate after the previous transmission.

[0150] This is a smoothing factor, ranging from 0.1 to 0.3, with a default value of 0.2.

[0151] This is the failure indicator function for the t-th transmission, and its value is either 0 or 1.

[0152] initial value .

[0153] when When the threshold of 1% is exceeded, the host automatically rolls back all subsequent small data requests for that target to the standard PRP / SGL path and continuously monitors it; if If the number of transmissions drops below the threshold within the next T transmissions (T ranges from 1000 to 10000, with a default of 5000), the inline path will be re-enabled.

[0154] For multiple consecutive inline commands, the controller can aggregate completion entries in the completion queue to reduce the number of interrupts. The controller maintains an aggregation timer (default 10 microseconds) and an aggregation counter. Within the timer window, after each inline command is completed, the controller does not immediately write it to the completion queue, but instead records the command identifier in an internal aggregation buffer and increments the aggregation counter. When the timer times out or the aggregation buffer is full (reaching 8 commands), the controller encodes the command identifier in the aggregation buffer into a bitmap and writes it to a 16-byte completion entry in the completion queue. The status code field is set to the vendor-defined "aggregate completion" code 0x7E, and the lower 16 bits of the result field are stored in the bitmap. After the host-side interrupt handler reads the completion entry, it updates the commit queue head pointer in batches according to the bitmap. This aggregation mechanism is compatible with the standard NVMe completion queue format.

[0155] To facilitate a better understanding of the present invention by those skilled in the art, the present invention will be further described below with reference to specific embodiments.

[0156] Example 1: This example uses a storage-computing converged device to demonstrate the basic process of host-side inline writing and controller-side processing when there is sufficient contiguous space after the tail pointer of the submission queue. The host needs to send an SQL query predicate to the solid-state drive controller, with the payload being "SELECT COUNT(*) FROM table WHERE id=123", which is 96 bytes long after being serialized in the protocol buffer.

[0157] The host-side load assessment unit determines that 96 bytes ≤ 4096 bytes and proceeds to the inline path. The segmentation unit segments data into 64-byte segments: 96 bytes requires two data segments, i.e. The first segment is 063 bytes, the second segment is 6495 bytes, and the second segment is padded with zeros to the end to make it 64 bytes.

[0158] The command construction unit constructs an NVMe command (opcode is the custom "CSD_QUERY", Opcode=0x81). It writes 0 and 1 to bits 31 and 30 of double word 12 respectively, forming a combined command type code "01" (basic inline transfer mode). It writes 2 to the lower 8 bits of double word 13, 96 to double word 14, and a cyclic redundancy check (CR) checksum of -32 calculated for the 96-byte payload to double word 15. The PRP1 and PRP2 fields are set to zero.

[0159] The queue write unit obtains the current tail pointer Tail = 127, and the queue depth QD = 256. The required number of entries is 2 (1 command + 2 data). Since Tail + 2 = 129 ≤ QD, the entries are physically contiguous. The write operation sequentially writes the commands. First data segment written The second data segment is written. .

[0160] After executing the write memory barrier, the tail pointer is updated to 129 and written to the doorbell register via memory-mapped I / O to notify the controller.

[0161] After the controller detects an update to the doorbell register, it reads sequentially starting from the current head pointer (assuming Head=127). The first entry read is an inline command; the parsed combined command type code is "01", indicating a basic inline transmission mode, and then it extracts... , , checksum .

[0162] The controller's internal state machine is initially in an idle state. After detecting an update in the doorbell register, it enters the command acquisition state. After reading the command and finding the type code to be "01", it transitions to the inline data state and sets the decrementing counter. In inline data mode, the controller reads the second entry sequentially ( As the first data segment, C is reduced to 1; the third entry is read. As the second data segment, C is reduced to 0, and the state machine automatically returns to the idle state. The two data segments are concatenated, and the first 96 bytes are extracted to obtain the payload. The cyclic redundancy check (CRC) is calculated by subtracting 32. ,and The comparison confirms a match. The controller then sends the payload to the on-chip SQL computing engine to execute the query.

[0163] After processing is complete, the controller writes a normal completion entry (status code 0x00) to the completion queue and updates the submission queue head pointer. This triggers a message signal interruption.

[0164] Example 2: This example is basically the same as Example 1. It shows how to ensure write atomicity and data integrity when the tail pointer of the submission queue is at the end of the queue and the inline entry needs to cross the boundary of the circular buffer.

[0165] Assume the current tail pointer Tail = 254, queue depth QD = 256, and the required number of entries is 2 (1 command + 2 data). Since Tail + 2 = 256, which is exactly equal to QD, the host performs a split write: the first write starts from Tail = 254 and goes to the end (254, 255), and the second writes the remaining entries (0) from the beginning of the queue. This is the command write operation. First data segment written The second data segment is written. .

[0166] To ensure atomicity, the tail pointer is not updated or the doorbell register is not written between two writes. The tail pointer is updated all at once after all entries have been written and the memory barrier has been executed. And write to the doorbell register.

[0167] During reading, the controller reads sequentially from the current Head position. When the end of the queue is reached, it automatically jumps to the beginning position to retrieve the command, the first data segment, and the second data segment in sequence. This process ensures that the controller does not read incomplete inline data due to incomplete writing.

[0168] Example 3: This example is a further optimization based on Example 2. In this example, the robustness of the system under abnormal conditions is demonstrated, including three sub-scenarios: verification failure retransmission, queue space management and prediction reservation, and failure rate adaptive switching, which complements Example 2.

[0169] Specifically as follows:

[0170] (1) Verification failure and retransmission:

[0171] Based on Example 1, assume that the controller calculates the Cyclic Redundancy Check-32 checksum. With the command Inconsistency. The controller writes a completion entry to the completion queue, sets the status code to the vendor-defined value 0x7F, and updates the head pointer to 130. The host-side interrupt service routine recognizes the status code 0x7F and performs a retransmission: it retrieves the original payload (96 bytes) from the upper-layer application, executes the inline write process again, and this time the tail pointer has been updated to 130 (assuming no other commands), writes the command and data segments to the new slot, and updates the doorbell register. The original failed slots (127~129) have been consumed by the controller (the controller has already written the failed completion entry to the completion queue and updated the head pointer), so it does not affect queue synchronization. After a successful retransmission, the controller processes normally and returns a successful completion entry.

[0172] (2) Queue space management and predictive reservation:

[0173] The host checks the number of available entries before sending. Taking basic inline transmission mode as an example, let's assume... , The number of available entries is:

[0174]

[0175] At this point, the host pauses sending commands and caches them in the software queue until the controller consumes and updates them. Meanwhile, the host maintains the segment distribution of the most recent 20,000 inline commands: 80% 15% 4%, Occupying 1%. Assuming currently available space. (For example, the head pointer has been updated, and space has been freed up in the queue), required ,calculate For the basic inline transmission mode, the judgment condition is: (Right now ), satisfy; at the same time (Right now The condition is met, therefore the transmission is successful.

[0176] (3) Failure rate adaptive switching:

[0177] The host-side maintenance of the failure rate of target namespace identifier NSID=1 is calculated using an exponentially weighted moving average. Initial failure rate The first transmission failed. ,renew:

[0178]

[0179] The second transmission failed. ,renew:

[0180]

[0181] The third transmission failed. ,renew:

[0182]

[0183] After 3 consecutive failures If the threshold of 0.01 is exceeded, the host automatically switches all small data requests for that namespace to the standard PRP / SGL path. The subsequent 5000 successful transmissions will each... Exponentially weighted moving average smoothed Gradually decreasing. When When the threshold drops below 0.01, inline paths are re-enabled.

[0184] Example 4: This example uses a key-value storage solid-state drive as the application scenario to fully present the entire process from host-side data preparation, inline writing, controller-side identification and extraction to completion notification.

[0185] In practice, the host needs to send a key-value write command to the key-value storage SSD, with the key being "user:1001" and the value being "active". After serialization by the protocol buffer, the payload length is 64 bytes (including key and value encoding). In this embodiment, the submission queue depth is 256, the current tail pointer is 100, and the head pointer is 100 (the queue is empty).

[0186] Host-side data preparation and inline writing:

[0187] The host-side load assessment unit obtains the payload to be transmitted, with a length of 64 bytes. Since 64 bytes ≤ 4096 bytes, the inline transmission condition is met, and the transmission enters the inline path. The segmentation unit segments according to 64-byte boundaries: 64 bytes is exactly one complete data segment, i.e. The last segment does not need to be padded with zeros.

[0188] The command construction unit constructs a 64-byte NVMe command. In this embodiment, the vendor-defined opcode (Opcode=0x81) from the NVMe protocol is used to represent the key-value write command. Bits 31 and 30 of command double word 12 are written with 0 and 1 respectively, forming the combined command type code "01" (basic inline transfer mode). The lower 8 bits of double word 13 are used to write the data segment number. Double word 14 write payload original length The double-word 15 is written with a cyclic redundancy check (CR) of -32 checksum calculated for the 64-byte payload. Simultaneously, the PRP1 and PRP2 fields in the command are set to zero to ensure the controller does not mistakenly initiate direct memory access transfers.

[0189] The queue write unit retrieves the current submitted queue status: the queue base address is... The current tail pointer Tail = 100, and the queue depth QD = 256. The required number of entries is... Each entry is 64 bytes. Since Tail+2 = 102 ≤ QD, the entries are contiguous in physical memory. Write operations are performed sequentially:

[0190] Write command entries to address ;

[0191] Write the data segment (64-byte payload) to the address. .

[0192] After the write operation is complete, a write memory barrier is executed to ensure that all data is visible to high-speed peripheral component interconnect devices. The commit queue tail pointer is then updated. The new tail pointer value is written to the doorbell register of the solid-state drive controller through a memory-mapped I / O write operation, triggering the controller to read the submission queue.

[0193] The solid-state drive controller side identification and data extraction are as follows: After the controller detects that the doorbell register has been updated, it sequentially reads 64-byte entries starting from the current head pointer (Head=100) position of the submission queue.

[0194] The first entry (address) read The command was parsed as an NVMe command. The controller checked the combined command type code and found it to be "01", identifying it as a basic inline transport mode. The following was extracted from the command:

[0195] Number of data segments (From the lower 8 bits of double-word 13);

[0196] Original length of payload (From double character 14);

[0197] Cyclic Redundancy Check - 32-bit Checksum (From double character 15).

[0198] The controller's internal state machine enters the inline data state and sets a decrementing counter. Continue reading the next entry (address) sequentially. (This is the data segment.) After the counter is decremented to 0, the state machine automatically returns to the idle state.

[0199] The controller reads a 64-byte data segment and stores it in its internal static random access memory buffer. This is based on the original length of the payload. The first 64 bytes are truncated as the payload. A cyclic redundancy check (CRC) checksum of -32 is calculated on the truncated payload. , and in the command The comparison yielded consistent results.

[0200] After data verification is successful, the controller routes the payload to the key-value indexing engine based on the command opcode (0x81) and namespace identifier. The key-value indexing engine parses the keys and values ​​in the payload and performs the write operation.

[0201] After processing, the controller writes a 64-byte completion entry to the completion queue, containing the command identifier, status code (0x00 for success), and result value. The controller then updates the submission queue head pointer. The host is notified of the interruption via a message signal.

[0202] The interrupt handler on the host side reads the queue entry, identifies the status code as successful, updates the locally maintained commit queue head pointer to 102, and calls back to the upper-layer application to notify that the key-value write is complete.

[0203] In this embodiment, the inline transmission process of the 64-byte payload is as follows:

[0204] Actual transmission volume of high-speed peripheral component interconnection link: 64 bytes of command + 64 bytes of data segment = 128 bytes (only committed queue read transactions, no independent direct memory access data transactions);

[0205] Percentage of valid data: ;

[0206] Compared to the traditional PRP mode: The PRP mode requires the transmission of a complete 4KB physical page (4096 bytes), along with a PRP pointer list (at least one PRP entry, occupying 16 bytes) and a doorbell register write transaction (4-byte memory-mapped I / O write). The actual transmission volume of the high-speed peripheral component interconnect link is approximately 4096 + 16 + 4 = 4116 bytes. This solution reduces the high-speed peripheral component interconnect transmission volume to 128 bytes, resulting in a link bandwidth saving of:

[0207]

[0208] Direct memory access transaction count: This solution has only one commit queue read transaction and no independent direct memory access data transactions; in PRP mode, there is one doorbell register write, one PRP pointer read, one direct memory access data read, and at least three independent high-speed peripheral component interconnection transactions. This solution eliminates redundant direct memory access operations.

[0209] Example 5: This example is an optimized implementation of the present invention. It coordinates the command-data hybrid writing on the host side with the dedicated parsing state machine and hardware-level queue management unit on the controller side to form a closed-loop transmission system from the host memory to the internal processing unit of the controller.

[0210] The core of this embodiment lies in reorganizing the transmission path of small data by introducing a circular buffer bidirectional pointer synchronization, a prefetch descriptor, and a hardware order-preserving unit.

[0211] This embodiment optimizes the hardware logic on the controller side and the host-controller collaboration mechanism based on embodiment 4.

[0212] Taking a frequent small-data query scenario in in-memory computing devices as an example, the host needs to send a batch command consisting of 100 SQL predicates to the solid-state drive controller. The effective payload length of each predicate is randomly distributed between 32 bytes and 128 bytes, with an average length of 64 bytes. The target submission queue depth is 1024, and the current queue is empty, i.e., tail pointer Tail=0 and head pointer Head=0.

[0213] The steps to implement this on the host side are as follows:

[0214] S1': The host-side load assessment unit obtains the valid payload to be transmitted and determines its byte length L. Since the average length is 64 bytes and the preset threshold Th is set to 256 bytes, all payloads meet the inline transmission conditions.

[0215] S2': The segmentation unit segments the payload into 64-byte segments and calculates the required number of data segments N. Segment alignment optimization is introduced: if the payload length L is exactly a multiple of 64 bytes, the last segment is not padded with zeros; otherwise, zeros are padded to the end of the last segment to bring it to 64 bytes. The host generates a segment descriptor for each data segment. This descriptor includes the segment number (incrementing from 0), the payload length within the segment (64 bytes except for the last segment), and the length of the payload within the segment. If it is 0, then it is 64) and segment data (actual payload content, padding with zeros if less than 64 bytes).

[0216] S3', the command construction unit constructs a 64-byte NVMe command. Using a combined command type code, bits 31 and 30 of command double word 12 are set to 1 and 0 respectively, forming type code "10", indicating "inline small data transfer based on prefetch descriptor". The lower 8 bits of command double word 13 write the number of data segments N. The lower 16 bits of command double word 14 write the original payload length L. Command double word 15 writes the cyclic redundancy check (CRUD) checksum calculated over the entire payload. The PRP1 and PRP2 fields in the command are reused as "prefetch descriptor pointers", pointing to the relative offset of the prefetch descriptor in the commit queue (here, the prefetch descriptor immediately follows the command, with an offset of 1).

[0217] S4', The queue write unit performs the write operation. In this embodiment, the write operation employs a three-stage atomic write process: "command-descriptor-data".

[0218] First segment: Write the 64-byte NVMe command constructed in step S3' to the current tail pointer position of the commit queue.

[0219] The second step: Write the "prefetch descriptor" to the next slot in the commit queue. This descriptor itself is 64-byte aligned, consistent with the command entry format. The prefetch descriptor contains: the starting slot offset of the inline data in the commit queue (relative to the slot where the current command is located, which is 2 in this case), the number of data segments N, and the hardware ordering identifier (a 16-bit random number generated by the host).

[0220] Third segment: Write the N data segments generated in step S2' into the subsequent slots of the submission queue in sequence.

[0221] Therefore, a total of [number] needs to be written. (Order) (Prefetch descriptor) (Data segment) 64-byte entries.

[0222] S5' After executing the write memory barrier, update the tail pointer of the commit queue to the new position, and write the new tail pointer value to the doorbell register of the solid-state drive controller through a memory-mapped I / O write operation.

[0223] Solid State Drive Controller Side Implementation Steps

[0224] S7' After the controller detects an update to the doorbell register, its internal circular buffer management unit is triggered. This unit not only maintains the head pointer of each submission queue, but also a prefetch pointer, which points to the position where prefetching is needed next.

[0225] S8' The controller sequentially reads 64-byte entries starting from the current head pointer position of the submission queue. First, it reads the command, parsing bits 30-31 of the command double word 12, identifying it as command type code "10", and determining it to be an inline small data transfer based on the prefetch descriptor. The controller does not directly enter data fetching but instead enters prefetch mode.

[0226] S9' The controller actively reads the next entry (i.e., the prefetch descriptor) based on the command type. From this descriptor, it parses: the starting slot offset of the inline data in the queue (relative to the head pointer), the number of data segments N, and the hardware sequence identifier.

[0227] S10', The hardware sequence-keeping unit within the controller is activated. This unit uses an internal counter, along with information from the prefetch descriptor, to issue a multi-source aggregation transfer instruction to the direct memory access engine. This instruction instructs the direct memory access engine to:

[0228] Source address 1: Read 64 bytes from the head pointer position of the submission queue (where the command is located).

[0229] Source address 2: Read 64 bytes from the head pointer + 1 position of the commit queue (where the prefetch descriptor is located).

[0230] Source address 3 to source address N+2: Read N data segments from the head pointer +2 to the head pointer +N+1 position of the submission queue.

[0231] Target address: After aggregating all the above data, it is transmitted to a dedicated aggregation cache inside the controller.

[0232] S11' The Direct Memory Access (DMI) engine performs a one-time, continuous, multi-source aggregated DMI read. Because the commit queue may be physically non-contiguous (circular buffer), the DMI engine internally maintains a virtual address mapping table that maps the logical slots (circular) of the commit queue to contiguous physical memory addresses, thus ensuring the atomicity of the aggregated read. This process merges the read and join operations into a single DMI transaction at the hardware level.

[0233] S12' After the data is transmitted to the aggregate cache, the hardware ordering unit performs consistency verification on the command and data based on the hardware ordering identifier in the prefetch descriptor. After the verification passes, the data in the aggregate cache is organized into a protocol data unit and directly submitted to the upper-layer application processing unit (such as the SQL calculation engine or key-value index engine).

[0234] S13' After processing is complete, the controller writes a completion entry containing an aggregated completion bitmap to the completion queue. This bitmap not only indicates the completion of this command, but also indicates other completed commands in the same batch, realizing multi-command aggregation notification.

[0235] This embodiment expands the inline transfer indication from a single bit to an independent hardware descriptor by introducing a prefetch descriptor and a combined command type code, providing stronger indication capabilities. On the controller side, through the collaboration of the hardware order-preserving unit and the direct memory access engine, the process that originally required multiple reads and concatenations by the controller software is transformed into a one-time hardware-accelerated aggregated direct memory access transfer, reducing the load and latency of the controller CPU. The hardware order-preserving identifier in the prefetch descriptor, combined with the atomic aggregated read of the direct memory access engine, ensures the integrity and order of commands, descriptors, and data during transmission. By aggregating direct memory access reads and aggregating completion notifications, this embodiment pipelines and batches multiple small I / O processes, increasing the number of commands processed per unit time.

[0236] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0237] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. It should be noted that any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for transmitting inline small data based on NVMe command queues, characterized in that, include: Host-side steps: Obtain the payload to be transmitted. When the byte length of the payload is less than or equal to a preset threshold, segment the payload according to the preset data segment size boundary and calculate the required number of data segments N. Construct an NVMe command and set a combined command type code in the reserved field of the NVMe command. The combined command type code is used to indicate the inline transmission mode adopted by the current command. The inline transmission mode includes at least the basic inline transmission mode and the inline transmission mode based on the prefetch descriptor. When the combined command type code indicates the inline transmission mode based on the prefetch descriptor, construct the prefetch descriptor. The NVMe command, the prefetch descriptor when the combined command type code indicates an inline transfer mode based on a prefetch descriptor, and the N data segments obtained by segmentation are written as a series of consecutive 64-byte entries to the position indicated by the current tail pointer of the commit queue and its subsequent slots; after performing the write memory barrier operation, the tail pointer of the commit queue is updated, and the solid-state drive controller is notified by writing the doorbell register. Controller-side steps: Upon detecting a doorbell register update, 64-byte entries are sequentially read starting from the current head pointer position of the submission queue, and the combined command type code is parsed. If the combined command type code indicates a basic inline transfer mode, the number of data segments N is extracted from the command, and N data segments are read sequentially. If the combined command type code indicates a prefetch descriptor-based inline transfer mode, the next entry is read as a prefetch descriptor. Based on the information in the prefetch descriptor, the direct memory access engine is triggered to perform multi-source aggregation transfer, transmitting the NVMe command, the prefetch descriptor, and the N data segments as a continuous protocol data unit to the aggregation cache inside the controller in one go. After processing the acquired data, a completion entry is written to the completion queue, the head pointer of the submission queue is updated, and the host is notified via an interrupt.

2. The inline small data transmission method based on NVMe command queues according to claim 1, characterized in that, The combined command type code is formed by combining two or more reserved bits in the NVMe command. Different values ​​of the combined command type code correspond to standard NVMe protocol transmission, basic inline transmission mode, and inline transmission mode based on prefetch descriptors, respectively.

3. The inline small data transmission method based on NVMe command queues according to claim 1, characterized in that, The prefetch descriptor is a 64-byte aligned entry that includes the starting slot offset of the inline data in the submission queue, the number of data segments, and a hardware ordering identifier. The starting slot offset is used to indicate the offset position of the first data segment relative to the slot where the prefetch descriptor is located. The hardware ordering identifier is used by the controller to perform sequence consistency checks after the aggregated transmission is completed.

4. The inline small data transmission method based on NVMe command queues according to claim 1, characterized in that, The multi-source aggregation transfer is triggered by a hardware ordering unit within the controller. The hardware ordering unit maintains an internal counter and issues a multi-source aggregation transfer instruction to the direct memory access engine based on the information in the prefetch descriptor. The instruction contains multiple source addresses and a destination address. The multiple source addresses respectively point to the positions of the NVMe command, the prefetch descriptor, and the N data segments in the commit queue.

5. The inline small data transmission method based on NVMe command queues according to claim 4, characterized in that, The direct memory access engine internally maintains a virtual address mapping table to map the logical ring slots of the submission queue to contiguous physical memory addresses. When the multiple source addresses are not physically contiguous, the direct memory access engine performs a one-time continuous read according to the virtual address mapping table to ensure the atomicity of the aggregated transfer.

6. The inline small data transmission method based on NVMe command queues according to claim 1, characterized in that, The preset threshold is dynamically adjusted: the host maintains a historical load statistics module, records the actual effective load length distribution of the most recent M inline transmissions, calculates the average effective load length μ and standard deviation σ, and the threshold update formula is: Where M is the statistical window size, ranging from 1000 to 10000; μ is the average effective payload length, calculated using the following formula: L i Let be the effective payload length of the i-th inline transmission; σ is the standard deviation, calculated using the formula: ; k is a coefficient, ranging from 2 to 3; Th min The preset minimum threshold; Th max The preset maximum threshold; Th new This is the updated threshold.

7. The inline small data transmission method based on NVMe command queues according to claim 1, characterized in that, The preset data segment size is dynamically adjusted based on the maximum effective load negotiated by the high-speed peripheral component interconnection link, and the data segment size S satisfies... byte, ,and MPS represents the maximum effective load; the value of k is determined by the host based on the current effective load length L and MPS. Number of data segments required The last segment is padded with zeros to align with S.

8. The inline small data transmission method based on NVMe command queues according to claim 1, characterized in that, The host maintains a recently used payload hash table, recording the payload fingerprint and the corresponding cyclic redundancy check (CRUD) checksum. The fingerprint is calculated from the payload content using the Jenkins hash function. The hash table uses a least recently used eviction policy and has a fixed capacity of 1024 entries. Each hash table entry stores the payload fingerprint, checksum, and original payload length L. During retransmission, if both the payload fingerprint and length match, the stored checksum is reused directly; otherwise, the checksum is recalculated and the hash table is updated.

9. An inline small data transmission system based on NVMe command queues, used to implement the inline small data transmission method based on NVMe command queues as described in any one of claims 1 to 8, characterized in that, include: The host module is used to acquire the payload to be transmitted. When the byte length of the payload is less than or equal to a preset threshold, the payload is segmented according to a preset data segment size boundary, and the required number of data segments N is calculated. An NVMe command is constructed, and a combined command type code is set in the reserved field of the NVMe command. When the combined command type code indicates an inline transfer mode based on a prefetch descriptor, a prefetch descriptor is constructed. The NVMe command, the prefetch descriptor when the combined command type code indicates an inline transfer mode based on a prefetch descriptor, and the N data segments obtained from the segmentation are written as a series of consecutive 64-byte entries to the position indicated by the current tail pointer of the commit queue and its subsequent slots. After performing a write memory barrier operation, the tail pointer of the commit queue is updated, and the solid-state drive controller is notified through the write doorbell register. The solid-state drive controller module includes a ring buffer management unit, a hardware ordering unit, and a direct memory access engine; The circular buffer management unit is used to detect doorbell register updates and read entries sequentially from the submission queue; The hardware ordering unit is used to parse the combined command type code. If the combined command type code indicates a basic inline transfer mode, the number of data segments N is extracted from the command, and N data segments are read sequentially. If the combined command type code indicates an inline transfer mode based on a prefetch descriptor, the next entry is read as a prefetch descriptor, and the direct memory access engine is triggered to perform multi-source aggregation transfer, transmitting the NVMe command, the prefetch descriptor, and the N data segments as a continuous protocol data unit to the aggregation cache inside the controller in one go. The solid-state drive controller module is also used to process the data in the aggregated cache, write a completion entry to the completion queue, update the submission queue head pointer, and notify the host via an interrupt.

Images