One PCIe Read Can Request More Bytes Than a Data Packet Carries

MPS limits carried data; MRRS limits requested data

A transaction-layer packet, or TLP, is the packet being counted here. MPS bounds its applicable data payload, rather than the complete packet length including headers and other overhead. A Memory Write carries its data in the request. A Memory Read specifies an address and length, with the requested data arriving separately in successful Completion with Data TLPs.

MRRS concerns that requested length. It can exceed the payload limit applying to the returned packets. Xilinx's historical WP350 v1.2, dated October 28, 2014, explicitly explains this distinction and the need to divide returned data when the applicable MPS is smaller.

Thus a report showing MPS 256 bytes and MRRS 1024 bytes does not contain an inherent contradiction. One figure bounds carried data per applicable packet; the other bounds the data requested by one read. Neither establishes the complete application's transfer size.

References: [PS1][PS3]

Identify the reported limit and the actual transfer length

AMD's DMA/Bridge Subsystem for PCI Express guide PG195 v4.1, released December 18, 2024, reports separate maximum write-payload and maximum read-request quantities. Each reported value is the lesser of the corresponding PCIe IP value and subsystem parameter. Its encoded sizes are 128, 256, 512, 1024, 2048 and 4096 bytes.

These are definitions for that named implementation. In a GPU-server offer, ask the supplier to identify what its own fields report: supported capability, an effective configured limit or an actual transaction length. Those descriptions answer different questions.

A maximum is a ceiling. MRRS 1024 bytes does not require every read to request 1024 bytes. MPS 256 bytes likewise does not require every data-bearing packet to carry 256 bytes. The actual sizes remain part of the packet-accounting question.

References: [PS2][PS3]

Account for the same 1 KiB as a write and a read

Consider two separate, wholly fictional transfers using conventional PCIe transactions outside FLIT mode. Each moves 1 KiB, exactly 1024 bytes, beginning at a 4 KiB-aligned address. Stipulate an applicable MPS of 256 bytes for the writes and returned Completions, requester MRRS of 1024 bytes, valid request and Completion boundaries, and no errors, retries or other TLP traffic. Requests use the largest sizes permitted by these assumptions. For the read, additionally stipulate exactly four successful 256-byte Completion with Data TLPs.

The write carries 1024 / 256 = 4 data-bearing Memory Write request TLPs. Each carries 256 payload bytes, for 4 x 256 = 1024 bytes in the write direction. Conventional Memory Writes are posted, so this account requires no transaction-layer Completion response to them.

The read requests all 1024 bytes in 1024 / 1024 = 1 Memory Read request TLP. That request does not carry a 1024-byte payload. Its four stipulated Completion TLPs return 4 x 256 = 1024 data bytes in the opposite direction. Counting the request and its responses gives 1 + 4 = 5 TLPs.

Four and five therefore describe different packet accounts for the same data quantity. Counting only request packets gives four for the write and one for the read; counting only packets carrying the transferred data gives four in each case. The read's request length cannot be added to its returned payload and called 2048 bytes of transferred application data.

This finite account excludes link-control packets and supplies no elapsed time or on-wire byte total. It supports packet and payload arithmetic, without ranking read/write throughput.

References: [PS1][PC1][PC3]

Four return packets is a lower bound under those assumptions

With all 1024 requested bytes successfully returned and each Completion payload limited to 256 bytes, at least 1024 / 256 = 4 data-bearing Completion TLPs are needed. The exact four-packet result above additionally depends on the stipulated full-sized returns.

Now change only that stipulation: suppose the same read is returned as eight permitted 128-byte Completions. The payload total remains 8 x 128 = 1024 bytes, while the request-plus-response count becomes 1 + 8 = 9 TLPs. Nine packets would describe the same requested work divided differently.

Altera's P-Tile guide 25.1.1, dated December 15, 2025, permits multiple Completions for one Memory Read and illustrates several valid splits depending on address, length and Read Completion Boundary (RCB). RCB constrains permitted split boundaries; it does not force every Completion to carry exactly that many bytes. The related posted-request article develops those split rules.

References: [PC1]

Fewer requests for a block does not establish greater concurrency

Compare two more fictional read accounts for that aligned 1024-byte block. A has MRRS 512 bytes; B has MRRS 1024 bytes. Keep the applicable MPS at 256 bytes, use maximum-sized requests, and stipulate that every returned Completion carries 256 bytes. A sends two 512-byte requests, each answered by two Completions: 2 + 4 = 6 TLPs. B sends one 1024-byte request answered by four Completions: 1 + 4 = 5 TLPs.

B needs fewer request packets for this block under the assumptions. That result says nothing about how many requests A or B can keep outstanding simultaneously. A's two requests could be issued sequentially or overlap; the aggregate count does not tell us which occurred.

MRRS is measured in bytes per request. Concurrency counts requests still awaiting completion at a particular time. Altera's P-Tile documentation discusses tag allocation and outstanding non-posted requests separately, alongside the need to account for Completion buffering. Those implementation constraints require their own evidence.

Four Completion TLPs answering B's one read do not turn it into four independent outstanding read requests. Nor does doubling MRRS prove twice the transaction concurrency, half the latency or twice the payload rate.

References: [PC1][PC2]

Make the supplier comparison preserve all three quantities

For a proposed system, obtain the applicable payload and read-request limits with the exact device, implementation and transaction-mode context. Then distinguish what was requested from what the packets actually carried. A quoted maximum alone leaves actual request lengths and return splitting unresolved.

If an offer says it moves more data per request, the MRRS distinction may explain the claim. If it says it carries more data per Completion, ask for the actual return-payload evidence. If it says it keeps more work outstanding, ask for the defined outstanding-request limit and the observation supporting that claim. The same number cannot answer all three questions.

For a performance requirement, comparable evidence also needs the transferred byte population, direction, elapsed interval and operating conditions. The related generation-and-width article explains the separate link-capacity question. Combining a link label with MRRS still leaves delivered payload performance to be established.

Bring the selected system into a physical installation inquiry

When the customer and equipment supplier have selected the complete system, Leviathan's rack-and-stack service covers agreed equipment mounting, physical IT cabling, labels and installation records. Use the related service and project-inquiry links when that equipment needs a physical installation package.

Provide a nonconfidential equipment summary, appointed supplier, released rack and external connection plans, site constraints and required handoff. Device configuration and workload acceptance remain with their appointed technical owners. This educational packet account supplies no field procedure or approval to operate equipment.

References: [L1]