By default, when a large Transaction Layer Packet (TLP) arrives at a PCIe Switch, the Switch’s Ingress Port uses a traditional “store-and-forward” method. The Ingress Port stores the entire incoming packet and evaluates its 32-bit Link Cyclic Redundancy Code (LCRC) for errors before it ever attempts to forward the data to the correct Egress Port. While this method is highly reliable, waiting for a large packet to fully arrive before routing it can create significant transfer latency.
To minimize this latency, the PCIe specification supports an optimization feature known as Cut-Through Mode.
Here is a look at how Cut-Through Mode safely bends the rules to accelerate large TLP routing, and the clever mechanism it uses to handle unexpected mid-flight errors.
The Cut-Through Solution
Because the crucial routing information for a TLP is located at the very beginning of the packet inside its header, a Switch does not actually need the entire payload to know where the packet is going.
In Cut-Through Mode, the Switch assumes the incoming packet is perfectly good and begins evaluating the header’s routing information before the entire payload has been received. Once the destination is determined, the Switch immediately begins forwarding the TLP out of the Egress Port while the rest of the packet is still arriving at the Ingress Port. (The only restriction is that the Switch must ensure this won’t cause an “underflow” condition, which could happen if a slow x1 Ingress Port tries to feed a fast x16 Egress Port).
The Catch: Mid-Flight Errors
The inherent risk of Cut-Through Mode is that the Switch cannot verify the packet’s physical integrity until the LCRC arrives at the very end of the packet.
If the Ingress Port finally reads the LCRC and discovers a bit error, it takes standard action and immediately sends a “Nak” back to the original source to demand a replay. However, the Switch is now left with a major problem: most of the corrupted packet has already been forwarded out of the Egress Port and is on its way to the next device.
The Switch cannot simply wait for the receiving device to discover the error and send its own Nak, because the Switch’s Egress Port currently holds the corrupted packet in its Replay Buffer; replaying a bad packet won’t fix the problem. Furthermore, the specification strictly prohibits truncating a bad packet in flight.
The Fix: Nullifying the Packet
To solve this mid-flight crisis, the Switch is required to completely “nullify” the outgoing packet.
When the Switch discovers the error, it alters the tail end of the TLP as it leaves the Egress Port. Instead of attaching the standard End Good (END) framing symbol, it attaches an End Bad (EDB) symbol. To make the corruption completely unambiguous, the Switch also inverts (calculates the 1’s complement of) the 32-bit LCRC before sending it.
Once the packet is nullified, the system treats the corrupted transmission as if it never existed:
- At the Egress Port: The Switch’s Egress Port immediately drops the corrupted packet from its Replay Buffer and rolls back its sequence counter (
NEXT_TRANSMIT_SEQ) by one. - At the Receiver: When the downstream device (like an Endpoint) receives a packet ending in an EDB symbol with an inverted LCRC, it silently discards the packet. Because it is a nullified packet, the receiver will not return a Nak, will not increment its expected sequence counter (NEXT_RCV_SEQ), and will not start its Ack/Nak timers.
Summary Switch Cut-Through Mode is a powerful optimization that dramatically reduces the time large packets spend navigating complex PCIe topologies. By boldly forwarding data based strictly on early header information, switches can achieve incredible speeds, relying on the elegant “nullification” process to seamlessly clean up the pipeline if a rare bit error occurs mid-transit.