Glossary

PFC

Priority-based Flow Control

What is PFC

PFC (Priority-based Flow Control) is an Ethernet flow-control mechanism that prevents packet loss on specific traffic priorities when a switch port becomes congested. It builds on the basic Ethernet PAUSE-frame mechanism, but instead of pausing everything on a link, it pauses only the priority (queue) that is actually running out of buffer — letting the rest of the traffic on that link keep flowing.

That selectivity is what makes PFC a core building block of lossless Ethernet. Standard Ethernet is allowed to drop frames when buffers fill, which is fine for most applications but damaging for loss-sensitive workloads such as RoCEv2-based AI training, HPC, and storage traffic. PFC lets a network designate a small number of queues as lossless, protecting them from buffer-overflow drops while leaving every other queue to behave as ordinary best-effort traffic.

How PFC Works

To understand PFC, it helps to start with classic Ethernet flow control. Picture a switch where ports A and B receive traffic and port C forwards it. If the combined incoming rate of A and B exceeds C's bandwidth, the excess packets accumulate in the switch's internal buffer. When buffer occupancy reaches a high-water threshold called XOFF, ports A and B send PAUSE frames with a non-zero time value, telling the sender at the other end to stop transmitting for a period. When occupancy later falls below a low-water threshold called XON, they send PAUSE frames with a time value of 0, telling the sender it may resume. All of this assumes both ends of each link support flow control and have it turned on.

PFC applies exactly the same XOFF/XON logic, but per priority. When the buffer attributed to one queue crosses its XOFF threshold, the switch sends a PAUSE frame for that priority only, and the upstream device halts just that traffic class. When occupancy drops below XON, a resume notification lets that queue's traffic start again. Other priorities on the same link are unaffected throughout.

A few practical rules govern how this behaves in a real network:

  • Both ends must have PFC enabled. A port can receive PFC PAUSE frames whether or not PFC is configured on it, but it only acts on them when PFC is switched on. For PFC to actually protect a flow, the function must be on at the local end and the far end — and, to avoid congestion loss anywhere along the path, on every port the flow traverses.

  • The thresholds matter. The XOFF and XON thresholds determine how early backpressure starts and when it stops. They depend on factors such as interface rate and cable length, because traffic already in flight on the wire keeps arriving for a short time after a PAUSE is sent — so faster links and longer cables need more headroom before the buffer actually fills.

  • Lossless queues are deliberately limited. Because buffers are a shared and finite resource, a switch supports only a small number of lossless queues, with the total lossless buffer allocation constrained by the size of the lossless pool.

PFC is rarely deployed alone in modern AI and data center fabrics. It typically works alongside ECN, which signals senders to slow down early, with PFC held in reserve as the fail-safe that guarantees zero loss if congestion intensifies anyway. This layered approach is the basis of DCQCN.

Why PFC is Beneficial

  • Delivers zero packet loss where it counts: Designated lossless queues are protected from buffer-overflow drops, which is essential for RoCEv2, storage, and other workloads where a single dropped packet can trigger expensive retransmission or stall an entire job.

  • Pauses only what is congested: Because PFC acts per priority rather than per link, one congested traffic class does not stop unrelated traffic sharing the same physical connection.

  • Works hop by hop with no sender-side changes to the path: Backpressure propagates upstream one hop at a time, so every switch along a flow's path can protect its own buffers without relying on end-to-end signaling.

  • Complements ECN rather than competing with it: With ECN handling early, gentle rate reduction, PFC serves as the safety net — giving a fabric both smooth performance in normal congestion and a hard guarantee in severe congestion.

  • Tunable to the link: Configurable buffer thresholds let operators match PFC behavior to actual interface speeds and cable lengths, rather than relying on a one-size-fits-all default.

The trade-off is that PFC is a blunt tool if overused: pausing a queue upstream can ripple backward through a network, and misconfiguration can lead to head-of-line blocking or, in the worst case, PFC deadlocks. That is why PFC deployments are normally paired with careful threshold tuning and a PFC watchdog.

At Asteraix

What We Can Do at Asteraix

AsterNOS provides PFC as a native, CLI-configurable feature, with lossless buffer tuning and a watchdog for deadlock protection.

  • Lossless queues ready out of the box: By default, queues 3 and 4 on all ports are lossless queues with PFC enabled, and the remaining queues are PFC-disabled. AsterNOS supports up to two PFC-enabled queues at a time.

  • Straightforward global enable and disable: priority-flow-control enable <ingress-queue> turns PFC on for one or more queues (range 0–7, for example 1 or 1 4), and no priority-flow-control enable <ingress-queue-id> turns it off. A save and reload (writereload) applies the change. Because PFC is evaluated on the ingress side of the traffic, it is configured at the ingress port.

  • Custom lossless buffer profiles: buffer profile <name> followed by mode lossless {static <static_th> | dynamic <dynamic_th>} size <size> ... lets operators define their own PFC buffers. On models other than CX308P-48Y-N-V2 and CX532P-N-V2, this includes xoff, xon-offset, and optionally xon thresholds, and static mode is recommended when using self-defined lossless buffers. The documentation notes that the sum of the lossless buffers allocated to each queue must not exceed the lossless pool size.

  • Documented, rate-and-distance-aware recommended values: AsterNOS's guide publishes recommended xoff values by interface rate and cable length — for example, at 400G over a 5 m cable, a recommended xoff of 117536 bytes, rising to 268640 bytes at 300 m — along with a recommended reservation size of 1518 bytes and an xon-offset of 13440 bytes. It also notes the model-specific cell sizes (128 bytes on CX308P-48Y-N-V2 and CX532P-N-V2, 224 bytes on other models) that thresholds should be multiples of.

  • Per-queue buffer binding through policy: A class-map matches the target queues (match cos <queue>), a policy-map binds the buffer profile to that class with priority-group-buffer <profile-name>, and service-policy applies it to the interface — keeping lossless buffer assignment consistent and auditable.

  • PFC Watchdog for deadlock protection: With PFC enabled, pfcwd enable {all | <interface_name>} detection-time <100–5000> [action {drop|forward|alert} | restoration-time <100–60000>] monitors for PFC-induced stalls and takes the configured action, with an optional polling interval (pfcwd interval, 100–3000 ms) and a pfcwd start_default shortcut for default settings.

  • Full operational visibility: show interface priority-flow-control, show buffer profile, show pfc profiles, and show counters priority-flow-control (with clear counters priority-flow-control to reset), plus show pfcwd configuration and show pfcwd stats, let operators confirm PFC state, buffer thresholds, pause counters, and watchdog activity directly from the CLI.