NVMe Base 2.4: Telemetry: capture and consistent retrieval

9 minute read

繁體中文

00.01.Telemetry exposes collected internal state as host-readable logs. The goal is a complete, consistent capture: who creates it, how large each area is, and whether it changes during segmented retrieval.

Host
The system running the operating system and issuing NVMe commands.

The main ideas

01

Establish who created the capture

01-01Host-initiated and controller-initiated logs have different creation and acknowledgment rules.

controller
Controller, the entity that implements the NVMe interface, fetches commands, and reports completions.
02

Use the header to find the data

02-01Read the header and area boundaries to plan retrieval. Standardized locations and vendor-specific payload formats answer different questions.

03

Keep segmented reads consistent

03-01Check capture identity and change information so that multiple reads do not combine data from different captures.

Connecting the main ideas

00.02.Distinguish host-initiated and controller-initiated logs, then use the header to establish area boundaries. Preserve capture identity across reads and acknowledge retrieval according to that log’s rules. Standardized locations do not define the contents of vendor-specific payloads.

01 Computing snapshots from Last Block

01.01.Areas are differently sized views starting at the same block 1. Read the fields the header, select the final applicable populated area, and do not add the three Last Block numbers.

Telemetry Data Areas are cumulativeThe header occupies block 0. Each Data Area starts at block 1, and larger areas include the data in smaller areas.HeaderBlock 0Area 1Area 2Area 3
The header occupies block 0. Each Data Area starts at block 1, and larger areas include the data in smaller areas.

01.02.Telemetry uses block 0 for its header and 512-byte blocks. Every Data Area begins at block 1. Areas 2/3/4 are larger cumulative sets, not disjoint regions placed after Area 1. Last Block is an inclusive block number; payload format and size are vendor-defined.

Sources: Base 2.4 §8.1.30; 5.2.13.1.8-5.2.13.1.9

Source: NVME-BASE-2.4, Rev. 2.4, §8.1.30; 5.2.13.1.8-5.2.13.1.9, printed pages 232-237,733-737, PDF pages 258-263,759-763

Computing snapshots from Last Block
Data areaIncluded blocksLast Block constraints
Area 11 through L1L1=0 means no data
Area 21 through L2L2 >= L1
Area 31 through L3L3 >= L2
Area 41 through L4Check support separately

02 Snapshot creation, chunked reads, and acknowledgement

02.01.Separate creating 07h data from subsequent reads; the controller decides 08h capture timing. For both, verify generation and distinguish event acknowledgement from payload deletion.

Keep segmented reads on one snapshot
  1. Read the header and save its generation number.
  2. Read the data in segments from the same snapshot.
  3. Read the header again and compare generation numbers.
  4. Treat the segments as one snapshot only when the generations match.
The generation number identifies a data version; creating a snapshot and reading an existing snapshot are different operations.

02.02.CTHID for LID 07h is CDW10 bit 8: one requests a new capture and zero does not update that snapshot. MCDA occupies bits 11:9 and applies only when MCDAS=1 and CTHID=1; 001b through 100b request creation through Areas 1 through 4, while 000b lets the controller decide. MCDAS comes from the LID Specific Parameter in Supported Log Pages.

CTHID
Create Telemetry Host-Initiated Data; the 07h capture request, cleared for subsequent reads of that snapshot.
MCDAS
Maximum Created Data Area Supported; bit 0 of the 07h LID Specific Parameter, advertising MCDA support.
MCDA
Maximum Created Data Area; selects the largest area to create when supported and capture is requested.
CDW
CDW (Command Dword): a 32-bit command field. In CDW10, 10 is the field index, not a byte offset.
LID
Log Page Identifier: selects the type of log page to read.
Sources: Base 2.4 §5.2.13.1.8

Source: NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.8, printed pages 232-235, PDF pages 258-261

Snapshot creation, chunked reads, and acknowledgement
Snapshot-control fieldAction or reportConsideration during chunked reads
CTHID=1Triggers a new 07h captureDo not create again for subsequent chunks
MCDALimits the areas createdCheck MCDAS first
RAE=1Retains the eventDoes not exclude another reader
TCDA=0No update since acknowledgementIn 2.4 it does not mean payload disappearance
TCDA
Telemetry Controller-Initiated Data Available; in 2.4, indicates an update since the last RAE=0 acknowledgement.
RAE
Retain Asynchronous Event; use one during Telemetry collection and zero to acknowledge completion.

Where to continue in the specification

03.01.Use the flow above to frame the problem, then open the corresponding sections for fields and full conditions. The Chinese tutorial also explains every in-scope figure with its takeaway, example, and details.

Concept to explainSpecification sections
Computing snapshots from Last BlockBase 2.4 §8.1.30; 5.2.13.1.8-5.2.13.1.9 · Base 2.4 §8.1.30; 5.2.30.1.15 · Base 2.4 §5.2.13.1.8-5.2.13.1.9
Snapshot creation, chunked reads, and acknowledgementBase 2.4 §5.2.13.1.8 · Base 2.4 §8.1.30 · Base 2.4 §5.2.13.1.9 · Base 2.4 §5.2.13.1.8-5.2.13.1.9 · Base 2.4 §8.1.30; 5.2.30.1.6
Open the complete Chinese tutorial and figure explanations →

Check your understanding

1. If Area 1 Last Block is 3 and Area 2 Last Block is 7, which payload blocks belong to Area 2?

04.01.Area 2 contains blocks 1 through 7, totaling 7×512=3584 bytes, including Area 1 blocks 1 through 3. The header is block 0 and occupies another 512 bytes. Last Block is inclusive.

Sources

Source: NVME-BASE-2.4, Rev. 2.4, §8.1.30; 5.2.13.1.8-5.2.13.1.9, printed pages 232-237,733-737, PDF pages 258-263,759-763

2. Why reread the Telemetry header after collecting its data in chunks?

04.02.A new snapshot generation may appear during collection. Rereading generation checks that the chunks still belong together; a change requires recollection. For controller-initiated data, also check TCDA to account for acknowledgement by another reader.

Sources

Source: NVME-BASE-2.4, Rev. 2.4, §8.1.30, printed pages 734-735, PDF pages 760-761

Source: NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.9, printed pages 237, PDF pages 263

Specification editions

NVM Express Base Specification, Revision 2.4

Jia-Chang

Jia-Chang

Human

Comments

  Write a comment ...