netlink-packet-devlink

Packet types for the devlink generic netlink family.

Unlike rtnetlink or RDMA netlink, devlink has no fixed protocol number: it is a generic netlink family whose id is resolved at runtime by asking the controller for "devlink". genetlink does the resolution; this crate provides the payload and implements GenlFamily.

Status

Read-only, aimed at the three things we actually want to reach:

Query	Command	State
devlink dev show	GET → NEW	works
devlink dev info (firmware versions)	INFO_GET	works
devlink dev eswitch show	ESWITCH_GET	works
devlink dev param show	PARAM_GET → PARAM_NEW	works
devlink port show	PORT_GET → PORT_NEW	modelled, untested
eswitch set, param set	ESWITCH_SET, PARAM_SET	commands modelled, no request builders yet

All 85 commands and 182 attributes have constants; 32 attributes have typed variants and the rest round-trip through DevlinkAttr::Other.

Requests and replies use different commands

A devlink query is not echoed back the way an RDMA nldev one is:

request	reply
DEVLINK_CMD_GET	DEVLINK_CMD_NEW
DEVLINK_CMD_PORT_GET	DEVLINK_CMD_PORT_NEW
DEVLINK_CMD_PARAM_GET	DEVLINK_CMD_PARAM_NEW
DEVLINK_CMD_ESWITCH_GET	DEVLINK_CMD_ESWITCH_GET
DEVLINK_CMD_INFO_GET	DEVLINK_CMD_INFO_GET

The first three change command; the last two do not.

Two traps worth knowing

Command numbers. The uapi header defines obsolete aliases as multi-line #defines:

	DEVLINK_CMD_ESWITCH_GET,
#define DEVLINK_CMD_ESWITCH_MODE_GET /* obsolete, never use this! */ \
	DEVLINK_CMD_ESWITCH_GET

The continuation line is indistinguishable from an enum entry. Counting it shifts every command after ESWITCH_GET by two, which sends well-formed requests to the wrong command — the kernel then answers EINVAL or EPERM, neither of which points at the cause. command_numbers_match_the_wire pins the values against a strace of devlink(8).

doit requests need NLM_F_ACK. A dump is terminated by NLMSG_DONE, but a non-dump request is terminated by nothing unless you ask for an acknowledgement. Without it the response stream never ends and the caller hangs after reading the single reply.

Parameter values are untyped on the wire

DEVLINK_ATTR_PARAM_VALUE_DATA carries no type of its own: a bool is zero-length, and the integer widths are indistinguishable from short strings. DevlinkAttr::ParamValueData therefore keeps raw bytes; interpret them with the sibling DevlinkAttr::ParamType. Note the kernel spells the boolean type DEVLINK_PARAM_TYPE_BOOL but its wire value is the FLAG one.

Testing

cargo test --features bolero        # property tests + wire regressions
cargo run --example devlink_info    # against the running kernel

devlink_info on a host with a ConnectX and an Intel NIC:

pci/0000:02:00.0   (reply cmd New)
  driver mlx5_core  serial 8ca09b1d0485ee11800058a2e10431a8
    fixed    fw.psid                      MT_0000000883
    running  fw.version                   32.48.1000
    stored   fw.version                   32.48.1000
  eswitch mode      Legacy
  eswitch inline    0
  eswitch encap     1
  17 parameter(s)
    param enable_roce                  Some(Bool)
    param enable_sriov                 Some(Bool)

Verified field for field against devlink dev info, devlink dev eswitch show and devlink dev param show. The read side needs no privileges for dev show; everything else needs CAP_NET_ADMIN.