One NVMe Transfer Can Span Three Memory Pages and Two Logical Blocks

One command describes memory and storage addresses separately

For an ordinary NVMe read, the command identifies the namespace blocks to read and the destination buffer for their data. For a write, the buffer supplies the data for the addressed blocks. A memory pointer and a logical block address therefore locate different sides of the transfer.

In the PCIe model used here, a Submission Queue carries commands and the associated Completion Queue receives completion entries. The payload uses the command's data-buffer description. Reading three buffer-page references does not turn one command into three queue entries. The related queue article explains those resources separately.

A Physical Region Page, or PRP, entry describes a memory page using an address and offset. The configured page size determines the offset boundary. Scatter Gather Lists, or SGLs, provide another buffer-description mechanism where supported. The worked example uses ordinary PRP-based PCIe data transfer and no metadata. It is an explanation of an offer's quantities, not a descriptor-construction procedure.

References: [M1][M2][P1]

Follow 8,192 bytes across three memory pages

Stipulate one fictional read of two consecutive namespace logical blocks, each containing 4,096 data bytes. Also stipulate a configured NVMe memory-page size of 4,096 bytes, an initial buffer offset of 1,024 bytes and a valid supported command within all applicable transfer limits. These are teaching assumptions, not specifications or observations for a product.

The requested data quantity is 2 x 4,096 = 8,192 bytes. The first buffer page has 4,096 - 1,024 = 3,072 bytes available from the starting offset to its end. After those bytes, 8,192 - 3,072 = 5,120 bytes remain.

The next page contributes 4,096 bytes, leaving 1,024 bytes in the third. The payload is therefore 3,072 + 4,096 + 1,024 = 8,192 bytes across three data-buffer pages.

The logical-block boundary falls at a different point: the first block's 4,096 bytes comprise the first page's 3,072-byte portion plus 1,024 bytes in the next page. That second page also holds the first 3,072 bytes of the second block; its final 1,024 bytes occupy the third page. A data-buffer page is not required to hold exactly one logical block.

Now change only the hypothetical buffer's starting offset to zero. Two complete 4,096-byte pages cover the same 8,192 bytes. The namespace request still contains two logical blocks. This comparison changes the buffer placement without changing the requested storage range.

References: [M1][M2]

Keep PRP list storage outside the payload count

In this ordinary transfer, PRP1 identifies the initial data location. PRP2 can identify the second data page when the transfer crosses exactly one page boundary; when it crosses more than one, PRP2 points to a PRP list instead. This is the distinction described in Microsoft's NVME_COMMAND reference.

The offset example crosses two boundaries. Its list holds references to the remaining data pages. The aligned example crosses one boundary and uses the direct second-page role.

A list contains references rather than the requested dataset. Its descriptor bytes are additional description storage, outside the 8,192 payload bytes. Account for that storage separately: the three-page figure counts pages touched by payload, not a complete allocation footprint. It does not require a dedicated fourth page. A count labelled three pages is ambiguous until the supplier says whether it counts data pages, list storage or both.

References: [M2][N1]

An SGL data block is a memory region

Base Specification 2.0c describes an SGL Data Block with an address and a length in bytes. Its name does not mean a namespace logical block. SGL segments organize descriptors; they are another quantity to distinguish from data regions.

The controller reports supported SGL types, and transport rules constrain their use. Establish the applicable controller, command and transport before interpreting an SGL claim. PRP and SGL are not universally interchangeable options on every offered path.

For an offer quoting two SGL data regions, ask what byte ranges they describe. That count alone cannot establish two namespace blocks, two commands or two NAND operations. Similarly, a shorter descriptor list supplies no measured throughput, latency or zero-copy result. A performance claim needs evidence for the actual workload and implementation.

References: [N1]

Attach each page size to the quantity it defines

CC.MPS is the configured NVMe memory-page size used for PRP geometry. CAP.MPSMIN describes the controller's minimum supported memory-page size. MDTS, the Maximum Data Transfer Size field, uses that minimum as its reference unit when its nonzero value is decoded. The configured size can equal the supported minimum, but the two fields answer different questions.

The three-page calculation describes how an allowed 8,192-byte buffer span is represented. It does not calculate the controller's maximum transfer allowance. Nor does the presence of a PRP list permit a command to exceed that allowance. Use the related MDTS article for the ceiling calculation and its metadata qualifications.

A CPU huge-page mapping concerns host address translation. Its label does not establish the NVMe controller's selected CC.MPS. A NAND page concerns the storage medium. Neither can replace the configured memory-page input in this example. The related host huge-page article covers that separate mapping decision.

References: [M1][M3][M4][HP1]

Ask which address space a fragmentation claim describes

Suppose two offers each promise the example's one-command, two-logical-block read. One describes three data-buffer pages; the other describes two. The worked offset comparison is sufficient to show why that difference alone cannot rank their storage layout or performance. It does not establish why either real implementation produced its count.

Even within memory, page count leaves a missing relationship: are the referenced pages adjacent? The Base specification illustrates PRP lists for both contiguous and noncontiguous memory pages. Three references alone do not settle that question. Namespace continuity and physical NAND placement are separate questions again.

Ask the supplier to identify the controller and firmware, applicable specification and transport, command data length, namespace data bytes per logical block, configured memory-page size and initial offset. Have it label data pages, list-storage pages and SGL regions separately wherever those counts appear.

A useful supplier response connects the claim to its consequence. If the concern is buffer-description overhead, request that accounting boundary. If it is storage fragmentation, request the storage address space and evidence being discussed. If it is application speed, request representative workload evidence. The same unexplained page count cannot answer all three decisions.

References: [N1]

Connect a selected equipment change to its physical scope

If the platform assessment leads to a separately approved equipment change, Leviathan's Hardware Refresh & Physical Support service can discuss the associated physical replacement, recabling and records. Use the linked service and project inquiry with a nonconfidential equipment summary, approved replacement list, site, access window, appointed supplier and required physical handoff.

Identify the owners of storage configuration, data handling and return to service alongside that physical package. A PRP or SGL question by itself establishes no need to replace equipment or alter a connection.

References: [L1]