NVMe Self-Study Bank: Commands, completions and processing order
NVMe · Q1–328
Q31–Q43
Commands, completions and processing order
Follow submission, consumption, processing, completion and host reclamation to learn what each field proves. Ordering, arbitration, fairness and interrupts answer different questions; completion order alone cannot establish them all.
Each question is followed by its explanation. Start with the volume overview, then follow the field interpretations, comparisons or processes. Essential conditions and the normal path are visible from the start. All numerical examples are hypothetical. Status is written SCT/SC; h indicates hexadecimal.
- SCT
- Status Code Type
Five observations during one command lifetime
Evidence of progress is not evidence of success; identify the stage you actually observed.
| Stage | What is established | What is not yet established |
|---|---|---|
| SQE prepared | Host filled opcode, CID, NSID and data pointers | Controller visibility |
| SQ tail updated | Submission, with separately ensured memory visibility | Consumption or completion |
| A CQE reports an advanced SQHD | Consumption reached the reported position | Completion of all commands from those slots |
| Target CQE has valid phase | Correlate SQID+CID and inspect SCT/SC | Interrupt delivery or unconditional persistence |
| Host advances CQ head | Host consumed completions and released CQ space | Completion of other SQs or CIDs |
- SQE
- Submission Queue Entry
- CID
- Command Identifier, unique among outstanding commands in one SQ
- NSID
- Namespace Identifier
- CQE
- Completion Queue Entry
- SQID
- Submission Queue Identifier
- SCT
- Status Code Type
- CQ
- Completion Queue
Worked interpretation: SQ1/CID 7 and SQ2/CID 7 can coexist. In a shared CQ, CID 7 alone is insufficient: read SQID. Write persistence additionally requires WCE, FUA or Flush completion conditions, not only success status.
Sources: Base 2.4 §4.1.1 · Base 2.4 §4.2.1, 4.2.3–4.2.4 · Base 2.4 §3.4.1–3.4.5 · Base 2.4 §5.2.30.1.4 · NVM Command Set 1.3 §2.1.2–2.1.4
Review the terminology when needed
- Controller / namespace
- A controller receives commands and manages access. A namespace is a logical storage space that commands can address. An NVM subsystem contains controllers and nonvolatile storage resources.
- SQ / CQ / SQE / CQE
- Submission and Completion Queues carry command entries (SQEs) and completion entries (CQEs). QID identifies a queue, CID distinguishes outstanding commands in one SQ, and NSID identifies a namespace.
- Register / Identify / Feature / Log
- A register exposes control or state. Identify queries capabilities and attributes; features query or configure operation; log pages report specific state or records. FID, LID, CNS and CSI select features, logs, Identify structures and command sets.
- index / offset / zero-based
- An index selects an entry, usually starting at 0; an offset measures distance from an origin in specified units. A zero-based count encodes count−1, but not every zero-valued field is a count. A Dword is 4 bytes; a byte is 8 bits.
- Scope / reset / retention
- Scope names the affected objects; retention means preserving state. Controller Reset (clearing CC.EN) is one form of Controller Level Reset, or CLR. Different CLR triggers can retain different registers.
Questions in this volume
- Q31 · What do Opcode, CID, NSID, Data Pointer and command dwords mean?
- Q32 · How are nonzero reserved fields, illegal field combinations and unsupported opcodes handled?
- Q33 · Which statuses apply to invalid, inactive, unused and improperly broadcast NSIDs?
- Q34 · What are SQHD, SQID, CID, phase and status used for in a CQE?
- Q35 · How should Status Code Type and Status Code be decoded?
- Q36 · What do More and DNR mean, and does DNR=0 guarantee an immediate safe retry?
- Q37 · Why might a posted completion remain unprocessed by the host?
- Q38 · Must outstanding commands complete in submission order?
- Q39 · Which commands have ordering dependencies, and why is universal ordered completion unsafe to assume?
- Q40 · How do outstanding limits and CQ Full constrain further command handling?
- Q41 · How do Round Robin and Weighted Round Robin arbitration differ?
- Q42 · When do Urgent, High, Medium and Low queue priorities take effect?
- Q43 · How can arbitration be evaluated when multiple queues compete?
Q31 What do Opcode, CID, NSID, Data Pointer and command dwords mean?
- NSID
- Namespace Identifier
Follow the explanation
Encode the operation, target, data location and parameters into a command the controller can read.
1. Establish the source and scope
Opcode interpretation depends on the Admin/I/O command set; equal numeric values need not mean the same operation across sets.
Check capabilities such as OACS, ONCS and SGLS and the namespace CSI. Not every command uses every common field.
- CSI
- Command Set Identifier
2. Fields, units and worked interpretation
CDW0 contains OPC, FUSE, PSDT and CID. NSID selects the target, MPTR/DPTR describe data, and CDW10–15 are command-specific. The common command is 64 bytes.
Select command set, opcode/support, legal NSID/parameters, data/pointers and a unique outstanding CID, then submit. PCIe Admin commands use PRPs, not arbitrary SGLs.
Match completion by SQID+CID. Results may reside in the host buffer or CQE DW0/1, not solely Status.
3. Conditions that change the interpretation
Unsupported opcode uses Invalid Command Opcode (0/01h). Invalid defined fields generally use Invalid Field (0/02h), subject to specific error definitions.
Cross-check command-set context, support and payload size. A valid DPTR address does not prove sufficient described data length.
Sources: Base 2.4 §4.1.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Source locations for this question
Sources: Base 2.4 §4.1.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Q32 How are nonzero reserved fields, illegal field combinations and unsupported opcodes handled?
Follow the explanation
Distinguish reserved bits from reserved coded values in defined fields; not every reserved bit requires receiver validation.
1. Distinguish the failure conditions
Host construction requirements and controller validation requirements are separate.
The host shall zero reserved fields; the recipient need not check reserved bits/bytes/fields. A reserved coded value in a defined command field shall be reported as an error.
Unsupported/reserved opcode: 0/01h. Illegal defined field: generally 0/02h unless a specific status applies. Multiple faults usually permit choosing one; nonzero reserved bits do not universally mandate 0/02h.
2. Establish the cause from evidence
Use Base §1.4.1 reserved semantics, opcode support and the individual command's field restrictions.
Start from a zeroed SQE and populate used fields. Change one item per error exercise and record whether the requirement says shall or should.
3. Outcome and follow-up checks
A legal combination follows normal completion. Lack of reserved-bit checking does not make a nonzero host value legal.
Record both host violation and controller detection obligations to avoid labeling permitted nonchecking as a firmware bug.
First ask whether the modified item is a reserved bit or a reserved encoding within a defined field.
Sources: Base 2.4 §1.4.1 · Base 2.4 §4.1.1 · Base 2.4 §4.2.3 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Source locations for this question
Sources: Base 2.4 §1.4.1 · Base 2.4 §4.1.1 · Base 2.4 §4.2.3 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Q33 Which statuses apply to invalid, inactive, unused and improperly broadcast NSIDs?
Follow the explanation
Separate invalid identity, inactive namespace and a command that does not use NSID.
1. Distinguish the failure conditions
Active state is controller-relative. Accessibility through another path does not establish activity on this controller.
Distinguish zero, valid allocated, inactive and FFFFFFFFh identifiers. Each command defines the scope of FFFFFFFFh.
Figure 93 defaults: inactive on an NSID-using command returns 0/02h, invalid returns 0/0Bh. Unsupported broadcast or nonzero NSID on an unused field returns 0/02h. Command-specific exceptions take precedence.
2. Establish the cause from evidence
Use active/allocated lists and the command's NSID rules, then check command-specific exceptions.
Determine whether NSID is used, then permitted namespace state and broadcast support. Some Identify CNS values intentionally query allocated/inactive namespaces.
- CNS
- Controller or Namespace Structure, selecting Identify data
3. Outcome and follow-up checks
Legal targets follow the command's completion rules. Some queries define special replies for absent/inactive objects that override the generic rule.
Correlate the original NSID, the list at that time and CNS/FID/opcode rules. A current list alone may not explain a past request.
- CNS
- Controller or Namespace Structure, selecting Identify data
- FID
- Feature Identifier
First check whether the command uses the generic rule or defines an explicit exception.
Sources: Base 2.4 §4.1.1 · Base 2.4 §3.2.1 · Base 2.4 §4.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Source locations for this question
Sources: Base 2.4 §4.1.1 · Base 2.4 §3.2.1 · Base 2.4 §4.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Q34 What are SQHD, SQID, CID, phase and status used for in a CQE?
Follow the explanation
A CQE carries command result, identity and queue progress; these fields are not interchangeable.
1. Establish the source and scope
SQHD describes the identified SQ, P the CQ slot, and Status the command identified by SQID+CID.
Interpret using current queue configuration and the common CQE layout, not a feature-selected meaning of SQHD.
2. Fields, units and worked interpretation
DW2 contains SQHD/SQID; DW3 contains CID/P/Status; DW0/1 carry command-specific results. SQHD reports consumption when that CQE was constructed.
Validate P, match SQID+CID, decode status/results, update SQ slot availability and finally release the CQ slot.
Simulated data: the previously known Head of one SQ is 4. A valid CQE identifies that SQ and reports CID=9 and SQHD=8. With no wrap in between, SQHD establishes that the controller consumed entries in slots 4–7, allowing those SQ slots to be reused; CID and Status identify and report the result of command 9. Other consumed commands need not have completed, and their data buffers cannot be reclaimed merely because their SQ slots are reusable. Figure 98 notes that SQHD is captured when this CQE is created: by the time the host reads it, the controller’s actual Head might have advanced to 10, which this CQE alone cannot establish. Read Base 2.4 §3.3.1.2 for submission and consumption, Figure 98 for SQHD and SQID, then Figure 99 for CID, P and Status.
3. Conditions that change the interpretation
Decode SCT and SC together; P is not an error code. Malformed CQEs or unknown CIDs require checking memory/lifetimes, not inventing a new NVMe status.
Distinguish SQ consumption, command completion and data-buffer reclamation. Reusable SQ slots do not permit early release of command data.
Sources: Base 2.4 §4.2.1, 4.2.3–4.2.4 · Base 2.4 §3.3.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Source locations for this question
Sources: Base 2.4 §4.2.1, 4.2.3–4.2.4 · Base 2.4 §3.3.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Q35 How should Status Code Type and Status Code be decoded?
Follow the explanation
The same SC can mean different things under different SCTs; decode the pair.
1. Establish the source and scope
Status belongs to this completion and must be interpreted with opcode, command set and failure conditions.
Base defines common SCT/SC values; use NVM definitions for its specific codes, not another command set's table.
2. Fields, units and worked interpretation
In CQE DW3, SCT is bits 27:25, SC bits 24:17 and P bit 16. In the final 16-bit word, SCT occupies bits 11:9 and SC bits 8:1.
Confirm data width/endianness, extract SCT/SC, select the correct table, then inspect DNR, More, CRD and command-specific results.
- DNR
- Do Not Retry, a completion retry indication
SCT=0, SC=00h means Successful Completion, but matching and phase still matter; zero low bits alone do not establish a new valid success.
3. Conditions that change the interpretation
For example, 0/01h is Invalid Command Opcode and 1/01h Invalid Queue Identifier. SCT 2 is Media/Data Integrity, SCT 3 Path Related and SCT 7 Vendor Specific.
Preserve raw CQE bytes and decoded values. Tools that remove P or repack status cannot have their integers compared blindly.
Sources: Base 2.4 §4.2.3 · Base 2.4 §4.2.1, 4.2.3–4.2.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Source locations for this question
Sources: Base 2.4 §4.2.3 · Base 2.4 §4.2.1, 4.2.3–4.2.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Q36 What do More and DNR mean, and does DNR=0 guarantee an immediate safe retry?
- DNR
- Do Not Retry, a completion retry indication
Follow the explanation
Separate potential retry success, additional error information and retry safety.
1. Mechanism and scope
Decode the same CQE; DNR's identical-command retry semantics cover any controller in the same subsystem.
DNR does not establish that data was unchanged. More=1 points to additional status in LID 01h, not another completion.
- LID
- Log Page Identifier
2. Understand it through actions and results
The common bits always exist; CRD use additionally depends on Host Behavior Support.ACRE and Identify.CRDT1–3.
Decode the cause; with DNR=0, address transient conditions, respect valid CRD guidance and assess retry safety. For non-idempotent work, determine whether the earlier operation took effect.
Only the new CQE establishes retry success. DNR=0 means may succeed, not immediate or duplicate-free success.
3. Avoid a misleading conclusion
Repeating unchanged invalid parameters is not useful. Apply explicit DNR rules: Command Interrupted (0/21h) requires DNR=0 and may be returned only with ACRE enabled.
More=1 must correspond to associated additional Error Information. Interpret CRD only when DNR/ACRE make it applicable.
Sources: Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.30.1.15 · Base 2.4 §9.1–9.6.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Source locations for this question
Sources: Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.30.1.15 · Base 2.4 §9.1–9.6.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Q37 Why might a posted completion remain unprocessed by the host?
Follow the explanation
Separate completion posting, notification delivery and host consumption.
1. Preserve the evidence first
This involves CQ memory, host Head/expected phase and interrupt routing, not necessarily execution failure.
Check Create CQ.IEN/IV, the selected MSI/MSI-X mode, masks and interrupt features.
- MSI
- Message Signaled Interrupt
- MSI-X
- Message Signaled Interrupts Extension
For MSI-X inspect Function Mask, vector mask and PBA; ordinary MSI uses different INTMS/INTMC rules. CQE validity still depends on location and phase.
- MSI-X
- Message Signaled Interrupts Extension
- MSI
- Message Signaled Interrupt
2. Work through the possible causes
First check CQ/slot selection and expected phase before assuming interrupt loss.
Inspect the correct CQ Head and phase first. Process valid CQEs; investigate missing interrupts through IEN, IV, masks, coalescing and the host handler.
3. Connect observations to specification conditions
Polling can consume a valid completion without a one-to-one interrupt. Interrupt count need not equal completion count.
Missing an interrupt does not itself carry an NVMe error status; the CQE may be successful. Do not invent Internal Error for it.
Compare posting, masking, interrupt delivery and Head-update times. An IRQ is notification, not the completion payload itself.
Sources: Base 2.4 §4.2.1, 4.2.3–4.2.4 · PCIe Transport 1.4 §3.1–3.4 · PCIe Transport 1.4 §3.5 · Base 2.4 §5.2.30.2.1–5.2.30.2.2 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Source locations for this question
Sources: Base 2.4 §4.2.1, 4.2.3–4.2.4 · PCIe Transport 1.4 §3.1–3.4 · PCIe Transport 1.4 §3.5 · Base 2.4 §5.2.30.2.1–5.2.30.2.2 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Q38 Must outstanding commands complete in submission order?
Follow the explanation
Understand that queued submission order is not a universal execution/completion-order guarantee.
1. Which stages are ordered
Independent commands need not complete FIFO even within one SQ; nearby submission times across SQs do not establish dependency.
Check for a fused operation or command-specific ordering rule; FUSES advertises fused support.
Distinguish submitted, consumed, processing and completed stages. SQHD only reports consumption.
2. How the host handles dependencies
If B depends on A, wait for A's successful completion before submitting B. Apply Flush/FUA separately for persistence.
Independent Read B may legally complete before Read A; match by SQID/CID rather than submission-array order.
Out-of-order completion alone has no error status. Violations of defined multicommand sequences follow their own errors.
Test required causal relations rather than treating apparent reordering alone as noncompliance.
Sources: Base 2.4 §3.4.1–3.4.5 · NVM Command Set 1.3 §2.1.2–2.1.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Source locations for this question
Sources: Base 2.4 §3.4.1–3.4.5 · NVM Command Set 1.3 §2.1.2–2.1.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Q39 Which commands have ordering dependencies, and why is universal ordered completion unsafe to assume?
Follow the explanation
Explicitly establish real dependencies instead of treating queuing as a transaction mechanism.
1. Mechanism and scope
Examples include CQ-before-SQ creation, SQ-before-CQ deletion, successful Set Features before affected new commands, and supported fused pairs.
FUSE=01b/10b marks the first/second command. In PCIe they must be adjacent in one SQ and submitted by one Tail update.
2. Understand it through actions and results
Check FUSES and individual feature/command rules; no global ordered-mode bit resolves every case.
Establish ordinary dependencies by waiting for completion; submit fused pairs under their special rules with separate CQEs. Do not assume the controller orders arbitrary concurrent requests for the host.
Commands submitted after successful Set Features use the new value; previously submitted ones may use old or new settings. Drain first when testing a clean transition.
3. Avoid a misleading conclusion
A missing adjacent fused partner uses 0/0Ah. Queue dependency errors use Create/Delete-specific statuses, not universally 0/0Ch.
Trace completion-to-submission boundaries. FUA controls persistence, not these dependencies.
Sources: Base 2.4 §3.4.1–3.4.5 · Base 2.4 §5.3.1–5.3.2 · Base 2.4 §5.3.3–5.3.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · NVM Command Set 1.3 §2.1.2–2.1.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Source locations for this question
Sources: Base 2.4 §3.4.1–3.4.5 · Base 2.4 §5.3.1–5.3.2 · Base 2.4 §5.3.3–5.3.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · NVM Command Set 1.3 §2.1.2–2.1.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Q40 How do outstanding limits and CQ Full constrain further command handling?
Follow the explanation
Separate host submission capacity, internal execution resources and completion capacity instead of using one queue-depth value to explain every stall.
1. Mechanism and scope
Limits may affect an SQ, shared CQ or internal resources; not every limit is controller-wide failure.
Fetching submitted SQEs uses a vendor-specific algorithm; arbitration selects where candidate processing starts. Fetch and execution start are distinct.
2. Understand it through actions and results
The host uses queue size/SQHD and unique CIDs. Do not import another transport's MAXCMD flow-control assumptions into PCIe.
The host must not overwrite unconsumed SQEs; the controller must not post into a full CQ and may pause related further processing while independent SQs continue.
Progress resumes as capacity becomes available. A freed SQ slot can belong to a still-outstanding command because consumption is not completion.
3. Avoid a misleading conclusion
Normal resource limits do not automatically require error CQEs; pointer misuse, CID reuse and command-specific limits have separate rules.
Use evidence for each stage; submitted count does not establish simultaneous execution of every command.
Sources: Base 2.4 §3.3.1 · Base 2.4 §3.4.1–3.4.5 · Base 2.4 §4.2.1, 4.2.3–4.2.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Source locations for this question
Sources: Base 2.4 §3.3.1 · Base 2.4 §3.4.1–3.4.5 · Base 2.4 §4.2.1, 4.2.3–4.2.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Q41 How do Round Robin and Weighted Round Robin arbitration differ?
Follow the explanation
Select which SQ starts the next batch when several contain eligible work, allowing host service priorities.
1. What differs
Arbitration governs candidate processing starts, not completion order or a fixed IOPS ratio.
FID 01h provides AB and HPW/MPW/LPW; QPRIO applies in WRR. AB=7 means unlimited burst, otherwise 2^AB; weights encode value+1.
- FID
- Feature Identifier
2. How to choose and verify
All controllers support Round Robin. Discover optional WRR via CAP.AMS and select it with CC.AMS.
Select CC.AMS while disabled, set FID 01h after enabling, create SQ priorities and observe under continuously eligible workloads.
RR gives all SQs, including Admin, equal round-robin priority. WRR prioritizes Admin, then Urgent, then weighted High/Medium/Low service with within-class rules.
3. Conditions that shape the comparison
Unsupported CC.AMS programming is undefined, not a Set Features Invalid Field completion. Invalid defined FID 01h parameters follow command rules.
Get FID 01h verifies configuration only. Service time, media contention and CQ pressure affect throughput, so IOPS ratios alone cannot validate WRR.
Sources: Base 2.4 §3.4.1–3.4.5 · Base 2.4 §5.2.30.1.1 · Base 2.4 §3.1.4 (CAP, VS) · Base 2.4 §5.3.1–5.3.2 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events) · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §5.2.13.1.18
Source locations for this question
Sources: Base 2.4 §3.4.1–3.4.5 · Base 2.4 §5.2.30.1.1 · Base 2.4 §3.1.4 (CAP, VS) · Base 2.4 §5.3.1–5.3.2 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events) · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §5.2.13.1.18
Q42 When do Urgent, High, Medium and Low queue priorities take effect?
Follow the explanation
Give SQs different service opportunities only under the applicable arbitration mechanism.
1. Mechanism and scope
QPRIO is an SQ-level setting, not a per-Read/Write priority field.
Create SQ CDW11.QPRIO encodes Urgent 00b, High 01b, Medium 10b and Low 11b; FID 01h weights the latter three.
2. Understand it through actions and results
QPRIO is used only when WRR is supported and selected through CC.AMS; otherwise it shall be ignored.
Create SQs with suitable QPRIO. Change an existing queue through reconstruction, not by editing an old Create SQE in host memory.
Urgent outranks weighted service but remains below Admin. Persistent Urgent work may starve lower classes; High has no universal fixed minimum bandwidth.
3. Avoid a misleading conclusion
Ignoring QPRIO under RR is correct, not a failed priority feature. Invalid queue parameters still follow Create statuses.
Preserve each SQ's QPRIO, CC.AMS and FID 01h together; none alone explains priority behavior.
Sources: Base 2.4 §3.4.1–3.4.5 · Base 2.4 §5.3.1–5.3.2 · Base 2.4 §5.2.30.1.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events) · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §5.2.13.1.18
Source locations for this question
Sources: Base 2.4 §3.4.1–3.4.5 · Base 2.4 §5.3.1–5.3.2 · Base 2.4 §5.2.30.1.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events) · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §5.2.13.1.18
Q43 How can arbitration be evaluated when multiple queues compete?
Follow the explanation
Translate candidate-selection requirements into evidence rather than equating latency or throughput differences with arbitration violations.
1. Preserve the evidence first
Observe competing SQs on one controller after excluding CQ Full, dependencies, unequal service costs and insufficient offered work.
Record CAP.AMS, CC.AMS, FID 01h AB/weights and each SQ's QPRIO.
In WRR, processing starts per round are limited by remaining credits and AB. Ready candidates matter, not merely a nonempty SQ.
2. Work through the possible causes
First verify continuously eligible high-priority candidates and available CQ space.
Use comparable commands, sustained supply and nonblocking CQs. Compare processing-start/scheduler evidence where available; CQEs alone cannot reconstruct all internal choices.
3. Connect observations to specification conditions
High/Low weights of 4:1 describe service credits, not an exact completion ratio in every short interval.
Measurement itself has no error CQE. Verify configuration success and distinguish shall/may requirements; unsuitable workload conditions do not establish noncompliance.
A noncompliance claim needs a contradiction between a defined selection rule and evidence, not merely slower high-priority work.
Sources: Base 2.4 §3.4.1–3.4.5 · Base 2.4 §5.2.30.1.1 · Base 2.4 §5.3.1–5.3.2 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events) · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §5.2.13.1.18
Source locations for this question
Sources: Base 2.4 §3.4.1–3.4.5 · Base 2.4 §5.2.30.1.1 · Base 2.4 §5.3.1–5.3.2 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events) · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §5.2.13.1.18
Source locations and existing figure guides
Base printed page = PDF page−26; the other two use identical numbers. Locations follow the supplied PDF body and retain figure numbers. Shared pages contribute only the relevant definitions, excluding Fabrics and PCIe link/packet content.
- Base 2.4 · §1.4.1
Printed pages 2–3 · PDF 28–29 - Base 2.4 · §3.1.4 (CAP, VS)
Printed pages 54–59 · PDF 80–85 · Figure 36–37 - Base 2.4 · §3.2.1
Printed pages 78–81 · PDF 104–107 - Base 2.4 · §3.3.1
Printed pages 88–91 · PDF 114–117 · Figure 73–74 - Base 2.4 · §3.4.1–3.4.5
Printed pages 101–105 · PDF 127–131 · Figure 80–81 - Base 2.4 · §3.7.1–3.7.4
Printed pages 120–124 · PDF 146–150 - Base 2.4 · §4.1.1
Printed pages 139–142 · PDF 165–168 · Figure 92–93 - Base 2.4 · §4.2.1, 4.2.3–4.2.4
Printed pages 144–157 · PDF 170–183 · Figure 97–105, 109 - Base 2.4 · §4.2.3
Printed pages 145–155 · PDF 171–181 · Figure 101–105 - Base 2.4 · §4.4
Printed pages 166–169 · PDF 192–195 · Figure 126–127 - Base 2.4 · §5.2.2
Printed pages 183–190 · PDF 209–216 · Figure 150–156 - Base 2.4 · §5.2.13.1.2
Printed pages 218–220 · PDF 244–246 · Figure 212 - Base 2.4 · §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Printed pages 244–256, 258, 262–264 · PDF 270–282, 284, 288–290 · Figure 232–244, 246, 252–253 - Base 2.4 · §5.2.13.1.18
Printed pages 276–278 · PDF 302–304 · Figure 270–271 - Base 2.4 · §5.2.14.2.1
Printed pages 340–387 · PDF 366–413 · Figure 338–341 - Base 2.4 · §5.2.30.1 (common fields, scope and persistence)
Printed pages 456–460 · PDF 482–486 · Figure 463–466 - Base 2.4 · §5.2.30.1.1
Printed pages 460 · PDF 486 · Figure 467 - Base 2.4 · §5.2.30.1.4
Printed pages 464–465 · PDF 490–491 · Figure 471 - Base 2.4 · §5.2.30.1.15
Printed pages 475–477 · PDF 501–503 · Figure 491 - Base 2.4 · §5.2.30.2.1–5.2.30.2.2
Printed pages 514–515 · PDF 540–541 · Figure 543–544 - Base 2.4 · §5.3.1–5.3.2
Printed pages 527–531 · PDF 553–557 · Figure 571–579 - Base 2.4 · §5.3.3–5.3.4
Printed pages 531–532 · PDF 557–558 · Figure 580–583 - Base 2.4 · §9.1–9.6.1
Printed pages 825–826 · PDF 851–852 - NVM Command Set 1.3 · §2.1.2–2.1.4
Printed pages 14–20 · PDF 14–20 · Figure 3–9 - PCIe Transport 1.4 · §3.1–3.4
Printed pages 9–13 · PDF 9–13 · Figure 3–8 - PCIe Transport 1.4 · §3.5
Printed pages 13–16 · PDF 13–16 · Figure 9
When you need a field guide
Existing figure explanations have canonical locations; use these links instead of duplicating the same guide.
- Base 2.4 Figure 101 · Completion Queue Entry: Status Field
- Base 2.4 Figure 104 · Status Code – Command Specific Status Values
- Base 2.4 Figure 338 · Identify – Identify Controller Data Structure, I/O Command Set Independent
- Base 2.4 Figure 36 · Offset 0h: CAP – Controller Capabilities
- Base 2.4 Figure 543 · Interrupt Coalescing – Command Dword 11
- Base 2.4 Figure 93 · Common Command Format
- Base 2.4 Figure 97 · Common Completion Queue Entry Layout – Admin and All I/O Command Sets
Original documents used
- NVM Express Base Specification · Revision 2.4 · 2026-07-31
NVM-Express-Base-Specification-Revision-2.4-Ratified-2026.07.31.pdf - NVM Express NVM Command Set Specification · Revision 1.3 · 2026-07-31
NVM-Express-NVM-Command-Set-Specification-Revision-1.3-Ratified-2026.07.31.pdf - NVM Express NVMe over PCIe Transport Specification · Revision 1.4 · 2026-07-31
NVM-Express-NVMe-over-PCIe-Transport-Specification-Revision-1.4-Ratified-2026.07.31.pdf


Comments