Configure Priority Flow Control Safely with dcb pfc

Flip the wrong priority on with dcb pfc and you can trigger pause propagation across a switch fabric. Nobody notices until the link is already behaving strangely. This guide is a small, repeatable workflow for inspecting and changing Priority-based Flow Control on a Linux network device, using dcb from iproute2 6.1.0. PFC changes link behaviour, so use a maintenance window and confirm the device name before you set anything.

Allow about fifteen minutes for a read-only check, longer if you need to coordinate a live network change. You need iproute2, a device whose driver exposes the Linux DCB interface, and elevated privileges for changes. Reading settings is usually harmless, but the kernel or driver can still reject the request.

1. Confirm the installed tool

Start with ordinary, read-only checks. They tell you which binary and iproute2 release will actually interpret your commands:

$ command -v dcb
/usr/sbin/dcb
$ dcb -V
dcb utility, iproute2-6.1.0
$ dpkg-query -W -f='${Package} ${Version}\n' iproute2
iproute2 6.1.0-1ubuntu6.4

The installed package matters here. Syntax and supported attributes can vary between iproute2 releases and between network drivers. This guide follows the local dcb-pfc(8) and dcb(8) documentation, not a remembered version from somewhere else.

2. Check whether the device exposes PFC

Replace INTERFACE with the exact device name. This query does not change configuration:

$ sudo dcb pfc show dev INTERFACE
pfc-cap 8 macsec-bypass off delay 0
prio-pfc 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off

The output is device-specific. pfc-cap is read-only and reports how many traffic classes can support PFC at the same time. prio-pfc reports the enabled state for priorities 0 through 7. The example above is illustrative of a device with eight available classes, not a default you should expect.

See Attribute read: Operation not supported? The device or driver is not exposing the requested DCB attribute. Check the interface name with ip link, then check the driver documentation. Do not treat a rejected read as proof that PFC is safely disabled somewhere.

For a narrower read, name the fields you actually need:

$ sudo dcb pfc show dev INTERFACE pfc-cap prio-pfc delay
pfc-cap 8 delay 0
prio-pfc 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off

3. Record the current state before changing it

Save the complete output somewhere you will find it again. You will want the old values if the link starts behaving badly or the change needs reversing:

$ sudo dcb pfc show dev INTERFACE | tee pfc-before.txt

That file is ordinary local output, so pick a directory with sensible permissions on a shared host. Check that it actually contains the expected device state before you move on:

$ sed -n '1,5p' pfc-before.txt
pfc-cap 8 macsec-bypass off delay 0
prio-pfc 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off

There is no transaction or automatic rollback around dcb pfc set. This saved record is the actual undo mechanism. If another administrator changes the device between your read and your write, re-read it rather than overwriting their work blind.

4. Enable only the priorities you need

Use the writable prio-pfc array to enable priorities 6 and 7 while leaving everything else as it is:

$ sudo dcb pfc set dev INTERFACE prio-pfc 6:on 7:on

Array entries use priority:value. Entries are processed left to right, and anything you omit is read from the kernel and kept as-is, which makes this form good for a targeted change. It does not configure the switch, the peer, or traffic classification for you; every part of a PFC design still has to agree.

Verify the result immediately:

$ sudo dcb pfc show dev INTERFACE prio-pfc
prio-pfc 0:off 1:off 2:off 3:off 4:off 5:off 6:on 7:on

If the command fails, check its exit status and query the device again. A non-zero status means it failed. Do not assume a partial or cached-looking value actually made it onto the wire.

5. Set every priority deliberately when needed

To establish a known policy in one go, use the special all key first, then override the exceptions. This example turns PFC off everywhere except 6 and 7, and sets the propagation-delay allowance to hexadecimal 0x1000, which is 4096 bits:

$ sudo dcb pfc set dev INTERFACE \
    prio-pfc all:off 6:on 7:on \
    delay 0x1000

Later entries win, so order matters here. The valid priority range is 0 to 7. The delay value must sit between 0 and 65535 and represents an allowance for round-trip link propagation delay in bits, not a time in milliseconds.

Use decimal output to compare the applied value against the command more easily:

$ sudo dcb pfc show dev INTERFACE prio-pfc delay
prio-pfc 0:off 1:off 2:off 3:off 4:off 5:off 6:on 7:on
delay 4096

$ sudo dcb pfc set dev INTERFACE prio-pfc all:off delay 0
$ sudo dcb pfc show dev INTERFACE prio-pfc delay

6. Check MACsec bypass separately

macsec-bypass is a separate writable attribute. It describes whether the sending station can skip MACsec processing when MACsec itself is disabled:

$ sudo dcb pfc show dev INTERFACE macsec-bypass
macsec-bypass off
$ sudo dcb pfc set dev INTERFACE macsec-bypass on
$ sudo dcb pfc show dev INTERFACE macsec-bypass
macsec-bypass on

Change this only when it matches the host's MACsec design and driver support: it is not a general performance switch. Put it back with sudo dcb pfc set dev INTERFACE macsec-bypass off if the setting was accidental.

7. Read PFC counters when diagnosing traffic

Request and indication counters are not part of the ordinary output. Ask for them explicitly, or add -s to include statistics:

$ sudo dcb -s pfc show dev INTERFACE
pfc-cap 8 macsec-bypass off delay 4096
prio-pfc 0:off 1:off 2:off 3:off 4:off 5:off 6:on 7:on
requests 0:0 1:0 2:0 3:0 4:0 5:0 6:12 7:8
indications 0:0 1:0 2:0 3:0 4:0 5:0 6:4 7:3

These names and numbers describe sent and received PFC frames per traffic class. They are evidence about observed traffic, not proof the whole end-to-end configuration is correct. Exact values, and even counter support, depend on the device.