PCIe Max Payload Size vs Max Read Request Size: MPS and MRRS Explained

PCI Express moves requests and completions as Transaction Layer Packets, or TLPs. Two similarly named settings describe different limits in that traffic: Maximum Payload Size (MPS) limits the data payload a Function may place in a TLP, while Maximum Read Request Size (MRRS) limits how much data a Function acting as a Requester may ask for in one Memory Read Request.

They are therefore not interchangeable bandwidth settings. MPS constrains payload carried in packets such as writes and read completions. MRRS constrains the requested byte count of a Memory Read Request. A read request itself does not carry the requested data; the Completer returns that data in one or more Completion TLPs subject to the applicable payload and completion-boundary rules.

A PCIe Function advertises the largest payload size it can support. Software then configures an active MPS value that must stay within the supported topology. Linux exposes helpers for reading and setting PCIe MPS and accepts the standard power-of-two values from 128 through 4096 bytes when the device supports them.

The active value matters across a hierarchy because packets traverse bridges and links, not just one endpoint in isolation. Linux therefore has PCIe bus policies that deliberately choose MPS according to the devices and buses in a topology. Its safe policy selects the largest value supported by all devices below the root complex, while its performance-oriented policy can choose values based on the parent bus.

MRRS is a field in PCIe Device Control for a Function acting as a Requester. Current NVM Express PCIe transport documentation describes it directly: a Function must not generate a Memory Read Request whose size exceeds the configured MRRS value. Linux likewise exposes pcie_get_readrq and pcie_set_readrq for the setting.

A larger request can reduce the number of separate read requests needed to fetch a larger region, but that does not turn MRRS into a simple throughput slider. The returned data can be split into multiple completions, and real performance also depends on device architecture, outstanding requests, latency, link capability, host behavior, workload and platform configuration.

Suppose a requester is allowed to issue a read larger than the payload size used for completion packets. The request can still be legal: the Completer can return the requested data through multiple Completion with Data TLPs. MRRS describes the request size; MPS still constrains packet payload.

This distinction explains why comparing the two numeric fields alone can be misleading. A system can legitimately expose an MRRS value larger than the active MPS. They govern different directions and packet roles rather than forming a rule that the two numbers must always match.

Linux documents several PCIe bus configuration policies. The safe policy chooses an MPS supported throughout the hierarchy below a root complex. The performance policy raises MPS according to the parent bus and also raises MRRS, while the peer-to-peer policy fixes MPS at 128 bytes so peer devices have a universally supported payload size.

Those policies are useful evidence that configuration is a system-level compatibility and performance decision. Firmware, operating systems and platform code already participate in choosing workable values. A desktop user should not assume that the largest number exposed by one endpoint is automatically the correct value for every device behind every bridge.

When diagnosing a PCIe device, separate transaction sizing from physical-link capability. A device can negotiate fewer lanes or a lower PCIe generation while still having valid MPS and MRRS settings. Conversely, a Gen 5 x16 link does not imply a particular transaction payload or read-request size.

For Linux diagnostics, tools such as lspci can expose PCIe capability and control fields, while kernel interfaces let drivers query MPS, MRRS, link speed and link width separately. For a practical investigation, record the endpoint, upstream bridges, negotiated speed and width, active MPS/MRRS, workload and any AER errors before changing one variable at a time.

Think of MPS as a ceiling on how much data one PCIe TLP may carry and MRRS as a ceiling on how much data a requester asks to read in one Memory Read Request. They can influence transaction overhead and how traffic is broken up, but neither replaces link bandwidth, latency, queueing or device-level behavior.

That model is also safer than copying tuning values from another PC. Different root complexes, switches, bridges and endpoints can advertise different capabilities, and the operating system must configure a coherent hierarchy. Use MPS and MRRS as diagnostic and architecture concepts first, not as generic optimization knobs.