Inspect and Safely Tune a devlink Device

You will use devlink to identify a kernel device, inspect its supported parameters and embedded switch state, then choose a safe next action such as a self-test or an explicitly planned reload. The examples follow the installed devlink-dev(8) interface from iproute2 6.1.0-1ubuntu6.4. Allow about fifteen minutes for inspection. A firmware flash or reload needs a maintenance window and device-specific documentation, so this guide does not perform either operation.

1. Check the installed command

Start with read-only version and help checks. These commands do not need elevated privileges:

$ devlink -V
devlink utility, iproute2-6.1.0
$ dpkg-query -W -f='${Package} ${Version}\n' iproute2
iproute2 6.1.0-1ubuntu6.4
$ devlink dev help

The option is -V, not the common GNU-style --version. The command may still be usable as an ordinary user, but access to a particular driver or device can depend on kernel and system policy.

2. Find the exact device identifier

List all devlink devices before using a device-specific command:

$ devlink dev show
pci/0000:01:00.0

Your output may contain no lines, or a different bus and address. Do not copy the identifier above unless it is present on your machine. Set a shell variable from your own output when a device exists:

$ DEV='pci/0000:01:00.0'
$ devlink dev show "$DEV"
pci/0000:01:00.0

Keep the value quoted. An empty result means there is no visible devlink device to configure, not that an invented identifier will work.

3. Inspect information before changing state

Read the device information and embedded switch settings first:

$ devlink dev info "$DEV"
$ devlink dev eswitch show "$DEV"
$ devlink dev param show "$DEV"

The exact fields are driver-dependent. Device information can distinguish fixed components from firmware versions that are running or stored. A running and stored firmware version can differ after a flash and before the required restart or reset. Parameter output tells you which names and configuration modes the driver actually supports, so use those names rather than guessing.

For one parameter, narrow the query after copying its exact name from the previous output:

$ PARAM='PARAMETER_FROM_DEVLINK_OUTPUT'
$ devlink dev param show "$DEV" name "$PARAM"

4. Run supported self-tests

Self-tests are a useful read-oriented starting point, but a test can still exercise hardware and affect service quality. Run them only when the driver documentation and maintenance plan allow it:

$ devlink dev selftests show "$DEV"
$ devlink dev selftests run "$DEV" id TEST_ID

Replace TEST_ID with an identifier printed by selftests show. Omitting id requests every supported self-test, which can take longer and may be more disruptive. A successful command means the requested test completed according to the driver; keep its output with the change record.

5. Understand parameter changes before applying one

There are three configuration modes. runtime applies while the driver is running and does not require a reset. driverinit stores a value for driver initialisation and requires a devlink reload to apply it. permanent writes the value to non-volatile device memory and requires a hard reset. The device must advertise the parameter and accept the chosen mode.

Changing a parameter is stateful and may alter traffic handling. Confirm the current value, the desired value, the driver's documentation and a recovery path before using a command like this:

$ devlink dev param set "$DEV" name PARAMETER value VALUE cmode runtime
$ devlink dev param show "$DEV" name PARAMETER

Replace both uppercase placeholders with values shown or documented for your device. There is no universal undo value: restore the previous value using the same command, if the driver still accepts it. Do not use permanent as a trial mode.

6. Treat reloads and firmware writes as maintenance work

$ devlink dev reload "$DEV" action driver_reinit limit no_reset

Without limit no_reset, the driver may reset or interrupt service as needed. Check the command's reported actions and verify the device afterwards:

$ devlink dev show "$DEV"
$ devlink dev info "$DEV"
$ devlink dev eswitch show "$DEV"

Firmware activation with action fw_activate can activate a pending image and may involve a firmware reset. Flashing is more irreversible: devlink dev flash "$DEV" file PATH writes device non-volatile memory, and the path must be available to the kernel firmware loader, such as under /lib/firmware. Verify the image, target and vendor procedure first, record the current dev info, and use the vendor's recovery process if the write fails. This guide intentionally gives no copy-and-paste flash command.

7. Diagnose the common failures

If devlink dev show is empty, check that the relevant driver is loaded and that the hardware exposes devlink support. If a device-specific command reports an unknown device, compare the bus and address character-for-character with devlink dev show. If a parameter is rejected, query devlink dev param show "$DEV" again and check that its supported configuration mode includes the one you selected.

After a reload or self-test, verify links and the service that owns the interface through your normal monitoring. If a parameter change causes trouble, restore the recorded previous value if the device is reachable; for a driverinit value, schedule the required reload. A permanent value may require a hard reset and cannot be treated as an ordinary runtime rollback.