PCIe Posted vs Non-Posted Transactions Explained

PCI Express is a packet-based interconnect. At the Transaction Layer, a requester creates Transaction Layer Packets, or TLPs, for operations such as memory reads and writes. Switches and the Root Complex route those packets through the PCIe hierarchy, and the destination that services a request is the completer.

The useful distinction for understanding request behavior is not simply read versus write. PCIe classifies traffic into posted requests, non-posted requests and completions. Linux PCIe tracing documentation exposes those three categories directly, while PCI-SIG material uses the same posted and non-posted terminology when describing ordering and protocol behavior.

A posted request is sent without requiring the destination to return a normal completion for that request. Memory Write is the most familiar PC example. A GPU, network adapter or storage controller can issue PCIe memory writes as part of moving data or updating memory-mapped state without receiving one completion packet for every write.

That does not mean PCIe writes are unprotected or that delivery is magically guaranteed outside the protocol. The Data Link Layer has its own reliability machinery for link transmission, and the architecture defines error handling and ordering rules. “Posted” specifically describes Transaction Layer response behavior; it is not a synonym for unreliable, asynchronous, DMA, or write-combining.

A Memory Read is a non-posted request. The requester cannot obtain the requested bytes from the request packet itself, so the completer returns one or more Completion TLPs carrying status and, for a successful read, data. Intel PCIe IP documentation explicitly tracks non-posted requests against corresponding completions and reports a completion timeout when a response does not arrive within the configured timeout behavior.

Other PCIe request types can also be non-posted, so “non-posted” should not be reduced to another spelling of “read.” The durable concept is that a response is required. This creates state at the requester: it must be able to associate a later completion with the request that caused it.

PCIe permits multiple non-posted requests to be outstanding at once. A requester therefore uses transaction identification, including a tag, so returning completions can be associated with the correct request rather than relying on one strictly serial request-response exchange.

Tag availability can become a real implementation resource. Current Linux documentation for Meta’s fbnic driver exposes a counter for outbound PCIe reads dropped because no tag was available, alongside counters for non-posted and completion credit exhaustion. That is useful evidence of the mechanism, but it is not a claim that ordinary desktop applications are commonly tag-limited or that a larger tag space guarantees a fixed performance gain.

One PCIe Memory Read request does not imply exactly one Completion TLP. Depending on the request, boundaries and platform behavior, requested data can be returned across multiple completions. Intel PCIe documentation shows examples where a single read is satisfied by several completion packets of different permitted sizes.

This is another reason not to equate a software read operation with one packet crossing the link in each direction. PCIe packetization, payload limits, completion boundaries and the device or Root Complex implementation all sit below the application-visible operation.

PCIe uses credit-based flow control so a transmitter does not send traffic that the receiving side lacks buffer capacity to accept. Implementations account for different traffic classes rather than treating every TLP as one undifferentiated stream. Intel describes dedicated receive buffering and credit checks for posted, non-posted and completion traffic, and Linux hardware-monitoring interfaces expose the same categories in PCIe counters.

Credits describe protocol buffering resources, not application bandwidth reservations. Running out of a particular credit can stall that class of traffic until credits become available, but the presence of separate credit pools does not create three independent physical links. The TLPs still share the underlying PCIe link and its negotiated generation and lane width.

PCIe does not simply require every packet to complete in issue order. The architecture defines ordering rules governing when different transaction classes may pass one another. PCI-SIG’s ordering material gives a concrete reason: a later non-posted transaction can be required to push prior posted writes so that a consumer does not observe a flag or read result before earlier data writes have reached the required point.

At the same time, PCIe supports mechanisms and attributes that permit more relaxed behavior where software and hardware can tolerate it. This balance matters for performance because strict serialization everywhere would waste concurrency, while unconstrained reordering could break producer-consumer correctness. The exact ordering rules are protocol rules, not a user-facing “latency mode” that should be toggled casually.

Because a non-posted request expects a response, implementations need a way to detect a completion that never arrives. PCIe defines completion-timeout behavior, and Intel documents hardware that tracks outstanding non-posted requests and reports when the corresponding completion does not arrive in time. PCI-SIG security material also distinguishes outstanding non-posted requests and their completion handling when discussing timeout-related behavior.

A completion timeout is therefore not a benchmark result saying that a device is merely “slow.” It indicates that a request-response transaction failed to complete within the applicable protocol timeout handling. Troubleshooting then belongs to the specific device, link, firmware, driver and platform context rather than to a universal timeout tweak.

The classification explains transaction semantics. It does not by itself establish SSD latency, GPU frame rate, NIC throughput or the performance of one PCIe generation versus another. Those outcomes also depend on link rate and width, payload efficiency, request sizes, concurrency, device architecture, software queues, memory behavior and workload characteristics.

For PC troubleshooting and performance analysis, use posted/non-posted/completion terminology to understand what traffic the link is carrying and why a response may be outstanding. Then measure the actual bottleneck. A Memory Write being posted is an architectural property; it is not evidence that writes are always faster than reads at the application level.