Host Interface Layer Namespace Queue Weighting
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing multi-tenant storage systems face challenges in achieving performance isolation among a large number of tenants, as previous solutions are not scalable to meet the demands of thousands of tenants while maintaining Quality of Service (QoS) and Service Level Agreements (SLAs).
Innovation Solution
A host interface layer architecture that utilizes Non-Volatile Memory Express (NVMe) standards to implement namespace (NS) and Non-Volatile Memory (NVM) Set-based performance isolation, with submission queues (SQs) assigned priority levels corresponding to Quality of Service (QoS) levels, allowing for end-to-end tenant isolation and dynamic weight adjustment based on storage capacity and priority.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If traditional queue-based command fetching is used, then basic command processing is achieved, but performance isolation and QoS control for large numbers of tenants cannot be provided
Solution Approach 1:
The patent segments the command processing system into multiple submission queues (SQs), each associated with specific namespaces and QoS levels. This segmentation allows independent management of commands for different tenants, enabling performance isolation while maintaining manageable complexity through structured organization of queues and namespaces.
Solution Approach 2:
The patent introduces a namespace (NS) as an intermediary layer between tenants and submission queues. The NS manager acts as a mediator that maps namespaces to QoS levels and manages the association between tenants and queues, simplifying the overall system complexity while enabling flexible multi-tenant isolation.
2Reliability
If more submission queues are created for more tenants, then tenant isolation is improved, but command fetching efficiency decreases due to increased context switching
Solution Approach 1:
The patent implements dynamic weight adjustment for submission queues based on current system state and QoS requirements. Weights can be modified at runtime to optimize command fetching efficiency while maintaining tenant isolation, allowing the system to adapt to changing workloads without sacrificing isolation guarantees.
Solution Approach 2:
The patent changes the parameter of queue weights dynamically based on QoS level requirements and system conditions. By adjusting weights rather than creating static queues for each tenant, the system maintains tenant isolation while optimizing command fetching efficiency through parameter modification.
3Reliability
If fixed priority queues are used, then QoS levels are enforced, but flexibility to adjust performance based on current workload is lost
Solution Approach 1:
The patent transforms fixed priority queues into dynamic queue structures where priorities and weights can be adjusted based on current workload conditions. This allows the system to maintain QoS guarantees while adapting to changing workload patterns, providing both reliability and flexibility.
Solution Approach 2:
The patent establishes QoS levels and weight configurations in advance for different tenant types, but allows runtime adjustment of these parameters. The preliminary configuration ensures QoS guarantees are built-in, while runtime adaptability allows optimization based on actual workload conditions.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
A host interface layer (510) in a storage device is described. The host interface layer (510) may include an arbitrator (605) to select a first submission queue (SQ) from a set including at least the first SQ and a second SQ. The first SQ may be associated with a first Quality of Service (QoS) level, and the second SQ may be associated with a second QoS level. A command fetcher (610) may retrieve an input/output (I/O) request from the first SQ. A command parser (615) may place the I/O request in a first command queue from a set (625) including at least the first command queue and a second command queue. The arbitrator (605) may be configured to select the first SQ based at least in part on a first weight associated with the first SQ and a second weight associated with the second SQ. The first weight may be based at least in part on a first total storage capacity of at least one first namespace (NS) associated with the first QoS level, and the second weight may be based at least in part on a second total storage capacity of at least one second NS associated with the second QoS level.