DEVLINK-DEV(8)

๐ŸŽ€ NAME ๐ŸŽ€

devlink-dev โ€” devlink device configuration, bestie. This is the page in the DEVLINK-DEV(8) family that handles all the device-level stuff: showing your devlink devices, flipping the eswitch around, poking parameters, hot reloading drivers, flashing firmware, and running selftests. Buckle up. ๐Ÿฆ‹


โœจ SYNOPSIS โœจ

devlink [ OPTIONS ] dev  { COMMAND | help }

OPTIONS := { -V[ersion] | -n[no-nice-names] }

devlink dev show [ DEV ]

devlink dev help

devlink dev eswitch set DEV [ mode { legacy | switchdev } ] [ inline-mode { none | link | network | transport } ] [ encap-mode { none | basic } ]

devlink dev eswitch show DEV

devlink dev param set DEV name PARAMETER [ value VALUE | default ] cmode { runtime | driverinit | permanent }

devlink dev param show [ DEV name PARAMETER ]

devlink dev reload DEV [ netns { PID | NAME | ID } ] [ action { driver_reinit | fw_activate } ] [ limit no_reset ]

devlink dev info [ DEV ]

devlink dev flash DEV file PATH [ target ID ]

devlink dev selftests show [ DEV ]

devlink dev selftests run DEV [ id ID...  ]

๐Ÿ’– DESCRIPTION ๐Ÿ’–

DEV โ€” tells you which devlink device to show off. If you don't pass this argument, literally every device gets listed. No cap. ๐Ÿ‘‘

Format is, and I need you to memorize this:

BUS_NAME/BUS_ADDRESS
  • mode { legacy | switchdev } โ€” sets the eswitch mode, periodt.
    • legacy โ€” Legacy SRIOV.
    • switchdev โ€” SRIOV switchdev offloads. the upgrade arc. โœจ
  • inline-mode { none | link | network | transport } โ€” some hardware devices need the VF driver to put part of the packet headers on the TX descriptor, so the e-switch can do proper matching and steering. it's giving teamwork fr.
    • none โ€” None.
    • link โ€” L2 mode.
    • network โ€” L3 mode.
    • transport โ€” L4 mode.
  • encap-mode { none | basic } โ€” sets eswitch encapsulation support.
    • none โ€” Disable encapsulation support.
    • basic โ€” Enable encapsulation support. ๐Ÿ’…
  • name PARAMETER โ€” specify the parameter name you want to set. icon behavior.
  • value VALUE โ€” the new value to set. Mutually exclusive with default. pick a lane bestie, you can't have both. ๐Ÿ™ˆ
  • default โ€” restores the parameter to its default value. Mutually exclusive with value.
  • cmode { runtime | driverinit | permanent } โ€” the configuration mode the new value gets set in.
    • runtime โ€” set the new value while the driver is running. This configuration mode doesn't require any reset to apply the new value. effortless, lowkey.
    • driverinit โ€” set the new value which will be applied during driver initialization. This configuration mode requires restarting the driver by the devlink reload command to apply the new value.
    • permanent โ€” the new value is written to the device's non-volatile memory. This configuration mode requires a hard reset to apply the new value. it's serious.
  • name PARAMETER โ€” specify the parameter name to show. If this argument is omitted, all parameters supported by devlink devices are listed. And here's the cute part: when the kernel provides a default value for a parameter, it will be automatically displayed in the output alongside the current value. two-for-one. ๐Ÿ“
  • DEV โ€” specifies the devlink device to reload.
  • netns { PID | NAME | ID } โ€” specifies the network namespace to reload into, either by pid, name or id.
  • action { driver_reinit | fw_activate } โ€” specifies the reload action required. If this argument is omitted, the driver_reinit action will be used. Heads up though: even though the user asks for a specific action, the driver implementation might require performing another action alongside it. For example, some drivers do not support driver reinitialization being performed without fw activation. Therefore, the devlink reload command returns the list of actions which were actually performed. it tells on itself, respectfully.
    • driver_reinit โ€” Driver entities re-initialization, applying devlink-param and devlink-resource values.
    • fw_activate โ€” Activates new firmware if such an image is stored and pending activation. If no limitation is specified, this action may involve firmware reset. If no new image is pending, this action will reload the current firmware image.
  • limit no_reset โ€” specifies a limitation on the reload action. If this argument is omitted, the limit is unspecified and the reload action is not limited. In such a case, the driver implementation may include reset or downtime as needed to perform the actions.
    • no_reset โ€” No reset allowed, no down time allowed, no link flap and no configuration is lost. the dream tbh. ๐Ÿ’–

Displays device information provided by the driver. You can use this command to query versions of the hardware components or device components which can't be updated (fixed), as well as device firmware which can be updated. For firmware components, running displays the versions of firmware currently loaded into the device, while stored reports the versions in the device's flash. Running and stored versions may differ after flash has been updated, but before reboot. yes bestie they can disagree, it's a whole thing. ๐Ÿ˜ญ

  • DEV โ€” specifies the devlink device to show. If this argument is omitted, all devices are listed.
This one writes to non-volatile memory. Read the arguments, then read them again.
  • DEV โ€” specifies the devlink device to write to.
  • file PATH โ€” Path to the file which will be written into the device's flash. The path needs to be relative to one of the directories searched by the kernel firmware loader, such as /lib/firmware.
  • component NAME โ€” if the device stores multiple firmware images in non-volatile memory, this parameter may be used to indicate which firmware image should be written. The value of NAME should match the component names from devlink dev info and may be driver-dependent.

(Also, the synopsis up top shows an optional [ target ID ] for this command. just so you know it's there.)

  • DEV โ€” specifies the devlink device. If this argument is omitted, all selftests for devlink devices are listed.
  • DEV โ€” specifies the devlink device to execute selftests.
  • id ID... โ€” the value of ID(s) should match the selftests shown in devlink dev selftests show to execute selftests on the devlink device. If this argument is omitted, all selftests supported by devlink devices are executed. go big or go home.

๐Ÿ“ EXAMPLES ๐Ÿ“

devlink dev show

Shows the state of all devlink devices on the system.

devlink dev show pci/0000:01:00.0

Shows the state of specified devlink device.

devlink dev eswitch show pci/0000:01:00.0

Shows the eswitch mode of specified devlink device.

devlink dev eswitch set pci/0000:01:00.0 mode switchdev

Sets the eswitch mode of specified devlink device to switchdev.

devlink dev param show pci/0000:01:00.0 name max_macs

Shows the parameter max_macs attributes. If a default value exists,
it will be displayed alongside the current value.

devlink dev param set pci/0000:01:00.0 name internal_error_reset value true cmode runtime

Sets the parameter internal_error_reset of specified devlink device
to true.

devlink dev param set pci/0000:01:00.0 name internal_error_reset default cmode runtime

Restores the parameter internal_error_reset of specified devlink
device to its default value.

devlink dev reload pci/0000:01:00.0

Performs hot reload of specified devlink device.

devlink dev flash pci/0000:01:00.0 file firmware.bin

Flashes the specified devlink device with provided firmware file
name. If the driver supports it, user gets updates about the flash
status. For example:
Preparing to flash
Flashing 100%
Flashing done

devlink dev selftests show pci/0000:01:00.0

Shows the supported selftests by the devlink device.

devlink dev selftests run pci/0000:01:00.0 id flash

Perform a flash test on the devlink device.

๐Ÿ‘‘ SEE ALSO ๐Ÿ‘‘

devlink(8), devlink-port(8), devlink-sb(8), devlink-monitor(8),


๐ŸŒธ AUTHOR ๐ŸŒธ

Jiri Pirko <jiri@mellanox.com>


okay that's the whole page bestie, you ate. this was iproute2, dated 14 Mar 2016, and the page is DEVLINK-DEV(8). go forth and configure responsibly ๐Ÿ’…โœจ๐Ÿซถ

๐Ÿ“ฆ where this page comes from