Tune Linux DCB Port Buffers with dcb-buffer
A single wrong number in a dcb buffer set command can starve one traffic class while another sits on a megabyte it never uses. This guide inspects the Data Centre Bridging buffer layout of a network port, then walks through a controlled change to the priority-to-buffer map and the buffer sizes themselves. It uses the dcb buffer subcommand from iproute2 6.1.0, installed on this system. Budget about 15 minutes for inspection, and a proper maintenance window for anything live.
The route
Jump straight to the step you need, or tick off Done means at the end.
- 1. Confirm the installed tool and target device
- 2. Read the complete current configuration
- 3. Inspect individual properties when troubleshooting
- 4. Plan a priority map before you touch the port
- 5. Change the buffer sizes during a maintenance window
- 6. Apply a priority map only after checking the baseline
- 7. Separate tool errors from hardware limits
DCB buffer settings are driver and hardware dependent. You need a DCB-capable interface, the dcb utility, and enough privilege to change its configuration. Reading may work as an ordinary user; changing a port normally needs root or the equivalent network administration capability. Do not try the write examples on a production interface during active traffic: a wrong mapping or buffer budget can hit latency, loss and pause behaviour all at once.
1. Confirm the installed tool and target device
Check the utility version and pin down the interface you actually mean to touch:
$ dcb -V
dcb utility, iproute2-6.1.0
$ ip -br link
PLACEHOLDER_IFACE UP ...
Swap PLACEHOLDER_IFACE for the real interface name, such as eth0, everywhere below. Keep the placeholder in your notes until the device is confirmed. This is not a general Ethernet buffer viewer: a laptop adapter, the loopback device, or a driver without DCB support will simply reject the request.
Checkpoint
The name after dev must be the physical or virtual interface whose DCB configuration you mean to change. A bond, a bridge and its member port can each have different capabilities and settings.
2. Read the complete current configuration
Start with a read-only query:
$ dcb buffer show dev PLACEHOLDER_IFACE
prio-buffer 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7
buffer-size 0:10Kb 1:10Kb 2:10Kb 3:10Kb 4:10Kb 5:10Kb 6:1Mb 7:10Kb
total-size 1222Kb
Your numbers will differ. With no property names, show reports the priority map, each buffer size and the total device memory used by port buffers. That total can be larger than the sum of the visible buffers, because the device may reserve buffers you never see listed.
Save the output before you change anything:
$ dcb buffer show dev PLACEHOLDER_IFACE | tee dcb-buffer.before
See Attribute read: Operation not supported? Stop here for this interface. That is a driver or capability boundary, not a reason to keep retrying with sudo. A successful read gives you a baseline, but it does not guarantee every write the driver will accept.
3. Inspect individual properties when troubleshooting
Use property names with no values to narrow the query:
$ dcb buffer show dev PLACEHOLDER_IFACE prio-buffer
$ dcb buffer show dev PLACEHOLDER_IFACE buffer-size
$ dcb buffer show dev PLACEHOLDER_IFACE total-size
prio-buffer maps priorities 0 through 7 to buffer indices 0 through 7. buffer-size reports the size of each of those buffers. total-size is read-only. The command prints the current kernel and driver view, so check it after a change instead of trusting the exit status alone.
4. Plan a priority map before you touch the port
The array syntax is a run of KEY:VALUE pairs. Here the key is a traffic priority and the value is a buffer index:
# Review this complete mapping before applying it.
prio-buffer 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7
That example is one-to-one, and it stays a plan right up until it appears in a set command. You can set one priority, say 3:2, or several at once. Anything you leave out of the array keeps its current value, so a partial command is not a hidden reset of everything else.
That retention rule is handy for a small tweak and easy to forget during a rushed change. Write down the final map you actually want and check it against the saved baseline before sending a partial one. The special key all sets one buffer index for every priority in a single stroke, which is exactly how a small typo turns into a whole-port mistake.
5. Change the buffer sizes during a maintenance window
Buffer sizes use buffer indices as keys and byte sizes as values. The tool takes a plain integer or suffixes such as K and M:
# Root or equivalent network administration privilege is required.
$ sudo dcb buffer set dev PLACEHOLDER_IFACE buffer-size all:10K 6:1M
This asks for 10K on every buffer, then overrides buffer 6 to 1M because later pairs win. The driver may round or cap the request to hardware limits, or reject a combination that overruns the device's memory. The spelling of the request is not proof of what actually got applied.
Check the interface name, the units and the exception before you press enter, because this is a live network change. If the driver accepts it, verify straight away:
$ sudo dcb buffer show dev PLACEHOLDER_IFACE buffer-size total-size
buffer-size 0:10Kb 1:10Kb 2:10Kb 3:10Kb 4:10Kb 5:10Kb 6:1Mb 7:10Kb
total-size 1222Kb
The exact output depends on the driver. A reported 10Kb in particular may just be the device rounding your 10K request. Compare the actual result against the adapter's documented capacity and performance limits.
6. Apply a priority map only after checking the baseline
Once the plan is approved, apply the complete map if you want a state you can audit later:
$ sudo dcb buffer set dev PLACEHOLDER_IFACE prio-buffer 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7
There is no transaction or rollback file for this command. Save the pre-change output, change one thing at a time, and verify after each step. If a command fails, capture the error and query the current state rather than assume everything earlier survived untouched.
Recovery
To undo the examples, restore the exact values from dcb-buffer.before, translating its two property lines back into explicit set commands. If your baseline held the one-to-one map and the sizes shown earlier, that looks like:
$ sudo dcb buffer set dev PLACEHOLDER_IFACE prio-buffer 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7
$ sudo dcb buffer set dev PLACEHOLDER_IFACE buffer-size 0:10K 1:10K 2:10K 3:10K 4:10K 5:10K 6:1M 7:10K
$ sudo dcb buffer show dev PLACEHOLDER_IFACE
Only run that restoration if those genuinely are your saved values. A reboot, link reset or driver reload might restore a device default of its own, but that is not a reliable undo method and it can disrupt service on its way.
7. Separate tool errors from hardware limits
A zero exit status means the command succeeded; a positive one means failure. For a failed read, check the device name and its DCB support. For a failed write, read the complete error, confirm the values you asked for sit within the adapter's documented limits, and check the result with show. More privilege will not fix a driver that simply does not expose the attribute.
A buffer configuration is only one piece of DCB. Priority handling, Enhanced Transmission Selection and priority flow control all interact with it, so change related settings as one coordinated design, not as isolated guesses chasing a big number in total-size.
Done means
- Confirmed the version and interface:
dcb -Vmatched the target device before you touched it. - Saved the complete pre-change output, and confirmed the interface supports DCB buffer attributes.
- Reviewed the priority map and buffer sizes as
KEY:VALUEpairs before any write. - Followed every live change with show, using the required privilege and checking the actual rounded or capped values.
- Kept a saved baseline as your recovery path, and did not keep hammering an unsupported device.