A method and system for ensuring quality of service (QoS) for multi-tenant NVMe solid-state drives based on protection information field extension.
By embedding QoS tokens in the protection information field of NVMe SSDs, hardware resources are dynamically scheduled, solving the "noisy neighbor" problem in multi-tenant shared scenarios, achieving hardware-level, fine-grained quality of service assurance, and improving performance determinism and resource utilization.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- ZESHI TECHNOLOGY (EZHOU) CO LTD
- Filing Date
- 2026-03-12
- Publication Date
- 2026-06-02
AI Technical Summary
In multi-tenant shared NVMe SSD scenarios, existing technologies lack hardware-level, fine-grained, and dynamically adjustable resource isolation mechanisms, causing high-priority applications to be interfered with by "noisy neighbors." Existing solutions, such as static partitioning, are inflexible, host-side scheduling cannot manage critical resources inside the SSD, and vendor-specific commands are coarse-grained and non-standard.
A custom QoS token is embedded in the protection information field of the NVMe protocol. QoS information is embedded in I/O commands through the host-side driver and parsed and executed by the SSD controller to dynamically allocate hardware resources such as NAND channels, GC, and DRAM cache, achieving hardware-level, fine-grained resource scheduling.
It achieves a reduction of over 40% in high-priority tenant I/O P99 latency, an increase of over 15% in storage resource utilization, and is highly compatible with the existing ecosystem, reducing deployment and upgrade costs.
Smart Images

Figure CN122131982A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer storage system performance management technology, specifically to a method and system for ensuring quality of service (QoS) for NVMe solid-state drives (SSDs) based on the extension of protection information fields. It is particularly suitable for achieving hardware-level, fine-grained input / output performance isolation and deterministic assurance in multi-tenant shared storage scenarios such as cloud computing and virtualized data centers. Background Technology
[0002] In cloud computing, virtualization, and containerized data center environments, to improve storage resource utilization and reduce costs, multiple virtual machines (VMs), containers, or different applications (collectively referred to as "tenants") typically need to share the same high-performance NVMe SSD. However, this sharing model introduces a significant performance interference problem: a tenant's intensive input / output (I / O) operations (such as log backups, big data analytics, and other background tasks) can severely consume shared resources within the SSD (such as NAND flash channels, controller DRAM cache, and background garbage collection (GC) bandwidth). This leads to drastic fluctuations in I / O performance, sharp increases in latency, and decreased throughput for latency-sensitive high-priority tenants (such as online transaction processing databases and real-time recommendation systems). This phenomenon, known as the "Noisy Neighbor" effect, undermines service level agreements (SLAs) for mission-critical applications and has become a core challenge that enterprise-level storage urgently needs to address.
[0003] To address this issue, the industry has proposed several solutions, but all have significant limitations: 1. Static partitioning based on NVMe namespaces; This method divides the physical SSD into multiple logical namespaces and assigns them to different tenants. While it provides a certain degree of isolation, its drawbacks are: (a) it requires pre-allocation of capacity in a static manner and cannot be dynamically adjusted according to the actual load of the tenant, resulting in low utilization of storage resources; (b) the isolation granularity is based on the entire namespace, which is too coarse and cannot further distinguish the priority of different I / O requests within the namespace.
[0004] 2. Host-side software I / O scheduling and throttling; For example, schedulers like blk-iocost in the Linux kernel attempt to perform priority scheduling and bandwidth limiting on the host side before I / O requests are submitted to the SSD. However, the bottleneck of such solutions is that: (a) their regulation only applies to the request queue level from the host to the SSD, and they cannot perceive or intervene in the more critical resource competition within the SSD controller, such as NAND flash media access conflicts, GC operations, cache replacement strategies, etc., which are the main sources of performance jitter; (b) software scheduling itself consumes host CPU resources.
[0005] 3. SSD vendor's proprietary QoS command set; Some enterprise-grade SSDs offer non-standard vendor-customized commands to limit bandwidth or IOPS for a namespace or the entire device. The shortcomings of such solutions are: (a) limited functionality, usually only bandwidth cap control, lacking fine-grained management of multi-dimensional resources such as latency and cache quotas; (b) reliance on proprietary interfaces of various vendors, resulting in poor interoperability and the inability to form an ecosystem standard; and (c) the granularity of control is still relatively coarse.
[0006] Furthermore, it's worth noting that the NVMe protocol standard itself defines a complete Protection Information (PI) mechanism, including Guard Tag, Application Tag, and Reference Tag fields. Its original design intent and industry-recognized sole purpose is to achieve end-to-end data integrity verification (E2E DIF), such as preventing logical block address (LBA) errors, data transmission corruption, or quiescent data corruption. Related standards (such as JEDEC JESD219) also explicitly classify it as a reliability feature. For a long time, the notion that "PI fields are only for data protection" has been a deeply ingrained technical bias, leading those skilled in the art to never consider reusing or extending it for entirely different performance scheduling and resource isolation purposes.
[0007] In summary, existing technologies lack a hardware-level, fine-grained, dynamically adjustable, and standard protocol-compatible quality of service (QoS) guarantee mechanism in multi-tenant shared NVMe SSD scenarios. On one hand, software solutions cannot reach the core of SSD internal hardware resource scheduling; on the other hand, any attempt to modify standard protocols or add dedicated hardware modules faces significant challenges in terms of compatibility, complexity, and cost. Therefore, an innovative solution is urgently needed that can penetrate the software layer and directly convey tenant and QoS intentions to the SSD hardware scheduler without altering the existing NVMe physical interface and core command set, thereby fundamentally suppressing "noisy neighbor" interference. Summary of the Invention
[0008] This invention designs a method and system for ensuring QoS for multi-tenant NVMe SSDs based on extended protection information fields. The technical problem it solves is that existing technologies, when multiple tenants share NVMe SSDs, suffer from performance fluctuations due to the lack of hardware-level, fine-grained resource isolation mechanisms, leading to interference from "noisy neighbors" and affecting high-priority applications. Existing solutions, such as inflexible static partitioning and host-side scheduling that cannot manage critical SSD resources (e.g., NAND channels, GC, cache), rely on coarse-grained and non-standardized vendor-specific commands. The core challenge lies in how to directly transmit tenant QoS intentions to the SSD controller while maintaining full compatibility with the NVMe protocol and without modifying the hardware interface, thereby achieving dynamic and fine-grained hardware resource scheduling and ensuring the deterministic I / O of critical services.
[0009] To solve the aforementioned technical problems, the present invention adopts the following solution: A method for ensuring QoS (Quality of Service) for multi-tenant NVMe solid-state drives based on protection information extension includes the following steps: S1, when the host sends an input / output (I / O) command to the solid-state drive, it reuses the Application Tag field within the NVMe standard protection information (PI) field of the I / O command, embedding a custom QoS token containing QoS information into the Application Tag field; wherein, the QoS information includes at least I / O priority and tenant identifier; S2, the solid-state drive controller receives the I / O command, and when it detects that the QoS-PI mode is enabled, it parses the Application Tag field to extract the QoS token, and decodes it to obtain the I / O priority and the tenant identifier; S3, the controller queries a preset resource allocation policy based on the decoded I / O priority, and dynamically allocates hardware resources inside the solid-state drive for the I / O command based on the policy; the hardware resources include at least one or more of the following: NAND flash channel access weight, garbage collection (GC) operation latency tolerance threshold, and DRAM cache quota.
[0010] Preferably, the QoS token is data occupying all 16 bits of the Application Tag field; wherein the high 4 bits are used to represent the I / O priority, and the low 12 bits are used to represent the tenant identifier.
[0011] Preferably, before step S1, the method further includes: the host side sending a first vendor-customized management command to the solid-state drive to enable the QoS-PI mode; wherein the opcode of the first vendor-customized management command is a predetermined value, and its command parameters include at least one flag bit for indicating whether the QoS-PI mode is enabled or disabled.
[0012] Preferably, the resource allocation strategy is stored in the controller's static random access memory (SRAM) and can be dynamically updated via a second vendor-customized management command.
[0013] Preferably, the tenant identifier is uniformly allocated, managed, and globally unique by the storage management software on the host side; after the QoS-PI mode is enabled, the controller passively receives and records the mapping relationship between the tenant identifier and the resource allocation.
[0014] Preferably, in step S3, dynamically allocating hardware resources for the I / O commands specifically includes: allocating higher NAND flash channel / Plane access weights to commands with higher I / O priorities, setting stricter GC latency tolerance threshold limits, and allocating a larger proportion of DRAM cache space.
[0015] Preferably, when the QoS-PI mode is not enabled, the controller processes the Application Tag field in the I / O command as part of the standard PI field and performs end-to-end data integrity verification.
[0016] A system for implementing the above method includes a host-side module and a solid-state drive (SSD)-side module: the host-side module is configured to embed a QoS token containing QoS information into the Application Tag field of a QoS PI (Quality Provider Interface) in an I / O command, and to control the activation of the QoS-PI mode through management commands; the SSD-side module, integrated in an SSD controller, includes: a parsing unit configured to parse the Application Tag field of the received I / O command to extract the QoS token and decode it when the QoS-PI mode is enabled; a policy storage unit configured to store resource allocation policies; and a scheduling unit configured to query the policy storage unit according to the decoded I / O priority, and dynamically schedule the hardware resources inside the SSD to execute the I / O command based on the query result.
[0017] Preferably, the host-side module is a modified NVMe driver to support the construction of the QoS token; the SSD-side module is implemented by updating the SSD controller firmware.
[0018] Preferably, when the QoS-PI mode is disabled, the system maintains full compatibility with standard NVMe protocol hosts, and the Application Tag field is restored to standard data protection purposes.
[0019] The method and system for ensuring quality of service for multi-tenant NVMe solid-state drives based on the extension of protection information fields have the following beneficial effects: (1) This invention achieves hardware-level, fine-grained QoS isolation. By directly embedding QoS information into I / O commands and having it parsed and executed by the SSD controller, this invention can dynamically schedule key competitive resources such as NAND channels, GC, and DRAM caches from the lowest level, thereby effectively isolating I / O interference between different tenants at the hardware level. Actual tests show that this solution can reduce the I / O P99 latency of high-priority tenants by more than 40%, fundamentally alleviating the "noisy neighbor" problem and providing deterministic performance guarantees for high-priority applications.
[0020] (2) This invention improves the utilization and flexibility of storage resources, eliminating the need for static pre-partitioning of physical SSD capacity (such as namespace partitioning), and realizing dynamic sharing of the entire disk capacity. Tenants are isolated only in terms of performance, not capacity, which allows storage resources to flow dynamically according to the actual load, significantly improving resource utilization (actual utilization can be improved by more than 15%), and avoiding resource waste or shortage caused by static allocation.
[0021] (3) This invention has excellent protocol compatibility and ease of implementation. It reuses the existing Protection Information (PI) field in the NVMe standard to transmit QoS information without introducing any new protocol fields or commands, and fully complies with the NVMe specification. This solution only requires upgrading the host driver and SSD firmware, without modifying the hardware interface or main control chip, achieving high compatibility with the existing ecosystem and greatly reducing deployment and upgrade costs.
[0022] (4) This invention innovatively extends the PI field, which was originally used only for data integrity verification, to the field of real-time performance scheduling for the first time, breaking the long-standing technical prejudice in this field that "the PI field is only used for data protection." This provides a completely new approach for achieving richer functional extensions within the framework of standard protocols.
[0023] (5) The resource allocation strategy of this invention can be updated online via management commands, enabling the service quality strategy to flexibly adapt to changing business needs. At the same time, this hardware-level protection mechanism provides auditable and measurable high-performance isolation capabilities for scenarios with strict performance compliance requirements, such as finance and healthcare. Attached Figure Description
[0024] Figure 1 This is a system architecture diagram provided in an embodiment of the present invention.
[0025] Figure 2 This is a structural diagram of the Extended Protection Information (PI) field provided in an embodiment of the present invention.
[0026] Figure 3 This is a flowchart of the SSD controller resource scheduling process provided in an embodiment of the present invention. Detailed Implementation
[0027] The following is combined with Figures 1 to 3 The present invention will be further described as follows: like Figure 1 As shown, the system architecture of this invention includes a host side and a solid-state drive (SSD) side. The host side includes a CPU, memory, and an NVMe driver that implements the functions of this invention. The core of the SSD side is the SSD controller, which internally houses key functional units such as an I / O parsing module and a QoS scheduler, and is connected to a NAND flash memory array composed of multiple planes. The host and the SSD communicate via a PCIe bus using the NVMe protocol.
[0028] The core of this invention lies in the fact that when the host driver initiates an I / O (read / write) command, it reuses the Protection Information (PI) field defined by the NVMe standard and embeds a custom QoS Token therein (see [link]). Figure 2 Upon receiving the command, the SSD controller parses the QoS Token and, based on its inherent priority and tenant identifier, dynamically allocates hardware resources (such as...) through its internal QoS scheduler. Figure 3 As shown in the figure, this enables the quality of service (QoS) guarantee for I / O requests from different tenants.
[0029] like Figure 2 As shown, this invention innovatively extends the application of the standard NVMe PI field.
[0030] A standard PI field consists of three parts: a Guard Tag (2 bytes), which is typically a CRC checksum calculated based on user data and used for end-to-end data integrity protection; an Application Tag (2 bytes), traditionally defined by the application layer, used for logical block address (LBA) range verification, etc.; and a Reference Tag (4 bytes), which is usually associated with the lower-order part of the LBA.
[0031] The key to this invention lies in the redefinition and utilization of the Application Tag field. For example... Figure 2 As shown, we define this 2-byte (16-bit) Application Tag as a QoS Token.
[0032] Its specific structure is as follows: The high 4 bits (Bits 15:12) are defined as I / O priority. They can represent 16 priority levels from 0 to 15, with smaller values indicating higher priority (e.g., 0 is the highest priority).
[0033] The lower 12 bits (Bits 11:0): Defined as a unique tenant ID. Supports a maximum of 4096 (2... 12 (Identifiers for different tenants)
[0034] The Guard Tag and Reference Tag fields still adhere to the standard NVMe protocol specification and are used for their original data integrity verification purpose. In this way, we can include critical information for QoS scheduling with each I / O request without increasing any additional protocol overhead or metadata bandwidth.
[0035] based on Figure 1 On the left, the Host-side driver implementation is as follows: The host-side NVMe driver needs to be modified to construct and inject the QoS Token when sending I / O commands.
[0036] The specific implementation steps include: 1. Enable QoS-PI mode; During system initialization or when needed, the host administrator enables the SSD's QoS-PI feature by sending a specific NVMe vendor-defined administrative command. This command can be defined as follows: Opcode: 0xC0 (example).
[0037] Parameter: Sets the "Enable" flag (e.g., 1 for enabled, 0 for disabled) in the least significant bit (Bit 0) of command DWord 10 (CDW10). The other bits of CDW10 and CDW11 through CDW15 are reserved and should be set to 0.
[0038] After receiving this command and verifying its validity, the SSD controller switches its internal state to QoS-PI mode and returns a success status.
[0039] 2. Construct and inject the QoS Token; When QoS-PI mode is enabled, the driver performs the following operations when preparing I / O commands with PI (such as write commands): Based on the identity of the tenant issuing the I / O request and its Service Level Agreement (SLA), determine the corresponding tenant ID and I / O priority.
[0040] according to Figure 2 The format shown shows that after shifting the priority left by 12 bits, a bitwise OR operation is performed with the tenant ID to synthesize a 16-bit qos_token.
[0041] Assign the synthesized qos_token to the app_tag field in the PI structure of the I / O command.
[0042] The other parts of the command (including user data, Guard Tag, Reference Tag, etc.) are constructed according to the standard procedure.
[0043] 3. Command Sending: The constructed I / O command is submitted to the SSD through the NVMe Submission Queue.
[0044] See Figure 1 Right side and appendix Figure 3 As shown, the SSD controller firmware is the core of hardware-level QoS scheduling. Its internal processing flow is as follows: Figure 3 As shown, the details are as follows: 1. Reception and Mode Determination: The SSD controller retrieves I / O commands from the submission queue. First, it checks the internal global status register to determine whether it is currently in QoS-PI mode (i.e., whether it has been enabled via the Opcode 0xC0 command).
[0045] 2. Standard Process Branch (Mode Not Enabled): If the QoS-PI mode is not enabled, the controller will treat the Application Tag in the command as part of the standard PI field and process the I / O command according to the traditional end-to-end data integrity verification process, ensuring full compatibility with standard hosts or SSDs that do not support this invention.
[0046] 3. QoS scheduling process branch (mode enabled): a. Parsing the QoS Token: The controller confirms that the command contains a PI and enters the QoS scheduling process. The I / O parsing module extracts the value of the app_tag field from the PI of the command.
[0047] b. Decoding Priority and Tenant ID: According to Figure 2 Define the format and decode the app_tag: priority = (app_tag >> 12) & 0xF; / / Extract the high 4 bits to get the priority. tenant_id = app_tag & 0xFFF; / / Extract the lower 12 bits to get the tenant ID. c. Query resource allocation policy: The QoS scheduler queries the resource allocation policy table stored in the controller's internal SRAM based on the decoded priority.
[0048] Table 1 defines the proportion of hardware resources available to different priority levels and the constraints therein. The strategy is illustrated below (and can be adjusted according to actual optimization): Priority range NAND Plane Access Weight GC maximum latency tolerance DRAM cache quota 0~3 (highest) 100% ≤ 10ms 80% 4~10 (Medium) 50% ≤ 100ms 15% 11~15 (lowest) 10% ≤ 1000ms 5% Table 1: Resource Allocation Strategy Table Note: This strategy design is based on a comprehensive assessment of typical business SLA requirements, SSD internal resource bottleneck analysis, and simulation optimization results. The strategy table can be dynamically updated via another vendor-customized management command (such as Opcode 0xC1) without requiring a device restart.
[0049] d. Dynamic resource allocation and scheduling: The QoS scheduler allocates specific resources for this I / O command according to the policy table. NAND Channel / Plane Scheduling: High-priority commands will have priority access to flash channels and planes, reducing queuing latency.
[0050] Garbage Collection (GC) Interference Management: For I / O from high-priority tenants, the controller will impose a stricter GC latency limit (e.g., 10ms) to prevent background GC operations from causing excessively long pauses in foreground I / O; I / O from low-priority tenants can tolerate longer GC latencies.
[0051] DRAM cache allocation: Allocate a larger proportion of DRAM cache space to high-priority tenants to improve their cache hit rate and speed up access.
[0052] e. Perform I / O: Under the allocated resource constraints, the controller performs actual NAND flash memory read or programming operations.
[0053] Tenant ID management and compatibility include the following: 1. Tenant ID Management: Tenant IDs are uniformly allocated, mapped, and reclaimed by the host-side storage management software (or virtualization manager), ensuring uniqueness among all tenants sharing the SSD. The SSD controller does not actively allocate IDs; it only passively receives and uses them. The host can use specific management commands (such as Opcode 0xC2) to notify the SSD to release internal resources associated with a particular tenant ID (such as clearing cache mapping entries).
[0054] 2. Backward compatibility: The design of this invention fully considers compatibility.
[0055] a. For hosts that do not support this invention: It will not send a Vendor Command (Opcode 0xC0) that enables QoS-PI mode. The SSD controller is always in the default "mode disabled" state, and all I / O commands are processed according to the standard PI procedure. The App Tag is used for traditional verification, and the system behavior is no different from that of a regular NVMe SSD.
[0056] b. For SSDs that do not support this invention: it will ignore or reject unknown Vendor Commands (Opcode 0xC0). The host driver can detect this failure and degrade to standard mode operation without affecting basic functions.
[0057] Therefore, this invention only activates the full hardware-level QoS guarantee function when both the Host driver and SSD firmware are upgraded to support it, thus achieving smooth compatibility with the existing ecosystem.
[0058] Through the specific implementation of the above-mentioned hardware and software collaboration, the present invention achieves hardware-level, fine-grained, and dynamically adjustable quality of service assurance for NVMe SSDs in multi-tenant shared scenarios, effectively suppressing interference from "noisy neighbors" and improving the performance determinism and resource utilization of storage services.
[0059] The present invention has been described above by way of example with reference to the accompanying drawings. Obviously, the implementation of the present invention is not limited to the above-described manner. Any improvements made using the inventive concept and technical solution of the present invention, or the direct application of the inventive concept and technical solution of the present invention to other occasions without modification, are all within the protection scope of the present invention.
Claims
1. A method for ensuring quality of service (QoS) for multi-tenant NVMe solid-state drives based on protection information extension, characterized in that, Includes the following steps: S1. When the host sends an input / output (I / O) command to the solid-state drive, it reuses the Application Tag field within the NVMe standard protection information (PI) field of the I / O command and embeds a custom QoS token containing QoS information into the Application Tag field; wherein, the QoS information includes at least I / O priority and tenant identifier. S2. The controller of the solid-state drive receives the I / O command. When it detects that the QoS-PI mode is enabled, it parses the Application Tag field to extract the QoS token and decodes it to obtain the I / O priority and the tenant identifier. S3. The controller queries a preset resource allocation strategy based on the decoded I / O priority, and dynamically allocates hardware resources inside the solid-state drive for the I / O command based on the strategy; the hardware resources include at least one or more of the following: NAND flash memory channel access weight, garbage collection (GC) operation latency tolerance threshold, and DRAM cache quota.
2. The method for ensuring QoS for multi-tenant NVMe solid-state drives based on protection information extension according to claim 1, characterized in that: The QoS token is a 16-bit data field that occupies all the bits of the Application Tag field; the high 4 bits are used to represent the I / O priority, and the low 12 bits are used to represent the tenant identifier.
3. The method for ensuring QoS for multi-tenant NVMe solid-state drives based on protection information extension according to claim 2, characterized in that: Before step S1, the following is also included: The host side enables the QoS-PI mode by sending a first vendor-customized management command to the solid-state drive; wherein the opcode of the first vendor-customized management command is a predetermined value, and its command parameters include at least one flag bit for indicating whether the QoS-PI mode is enabled or disabled.
4. The method for ensuring quality of service for multi-tenant NVMe solid-state drives based on protection information extension according to claim 3, characterized in that: The resource allocation strategy is stored in the controller's static random access memory (SRAM) and can be dynamically updated via customized management commands from a second vendor.
5. The method for ensuring QoS for multi-tenant NVMe solid-state drives based on protection information extension according to claim 1, characterized in that: The tenant identifier is uniformly allocated, managed, and globally unique by the storage management software on the host side; after the QoS-PI mode is enabled, the controller passively receives and records the mapping relationship between the tenant identifier and the resource allocation.
6. The method for ensuring quality of service for multi-tenant NVMe solid-state drives based on protection information extension according to claim 1, characterized in that: In step S3, dynamically allocating hardware resources for the I / O commands specifically includes: allocating higher NAND flash channel / Plane access weights to commands with higher I / O priorities, setting stricter GC latency tolerance threshold limits, and allocating a larger proportion of DRAM cache space.
7. The method for ensuring quality of service for multi-tenant NVMe solid-state drives based on protection information extension according to claim 1, characterized in that: When the QoS-PI mode is not enabled, the controller processes the Application Tag field in the I / O command as part of the standard PI field and performs end-to-end data integrity verification.
8. A system for implementing the method as described in any one of claims 1-7, characterized in that: Includes host-side modules and SSD-side modules: The host-side module is configured to embed a QoS token containing QoS information into the ApplicationTag field of the PI in the I / O command, and control the activation of the QoS-PI mode through management commands; The SSD-side module, integrated into the SSD controller, includes: a parsing unit configured to parse the Application Tag field of the received I / O command to extract the QoS token and decode it when QoS-PI mode is enabled; a policy storage unit configured to allocate storage resources; and a scheduling unit configured to query the policy storage unit according to the decoded I / O priority and dynamically schedule the hardware resources inside the SSD to execute the I / O command based on the query result.
9. The system according to claim 8, characterized in that: The host-side module is specifically a modified NVMe driver to support the construction of the QoS token; the SSD-side module is implemented by updating the SSD controller firmware.
10. The system according to claim 8, characterized in that: When the QoS-PI mode is disabled, the system maintains full compatibility with standard NVMe protocol hosts, and the Application Tag field is restored to standard data protection purposes.