docs: net: fix minor issues with devlink docs

Update devlink documentation to match current code:

- describe health reporter defaults (it's currently under "callbacks"),
  best-effort auto-dump, and port-scoped reporters
- fix generic parameter names and values
- fix nested devlink setup wording and registration ordering

Link: https://patch.msgid.link/20260613165846.2913092-3-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This commit is contained in:
Jakub Kicinski 2026-06-13 09:58:45 -07:00
parent c8ee634048
commit e504cf18ef
5 changed files with 23 additions and 14 deletions

View File

@ -33,7 +33,9 @@ Device driver can provide specific callbacks for each "health reporter", e.g.:
* Recovery procedures
* Diagnostics procedures
* Object dump procedures
* Out Of Box initial parameters
Drivers also provide default values for generic reporter parameters when
creating a health reporter.
Different parts of the driver can register different types of health reporters
with different handlers.
@ -45,8 +47,9 @@ Once an error is reported, devlink health will perform the following actions:
* A log is being send to the kernel trace events buffer
* Health status and statistics are being updated for the reporter instance
* Object dump is being taken and saved at the reporter instance (as long as
auto-dump is set and there is no other dump which is already stored)
* Object dump is being taken and saved at the reporter instance. This is
best effort and skipped when recovery is aborted, auto-dump is disabled,
no dump callback is registered, or a dump is already stored.
* Auto recovery attempt is being done. Depends on:
- Auto-recovery configuration
@ -75,7 +78,8 @@ User Interface
==============
User can access/change each reporter's parameters and driver specific callbacks
via ``devlink``, e.g per error type (per health reporter):
via ``devlink``, e.g. per error type (per health reporter). Reporters may be
registered for the whole devlink instance or for a specific devlink port.
* Configure reporter's generic parameters (like: disable/enable auto recovery)
* Invoke recovery procedure

View File

@ -122,7 +122,7 @@ own name.
* - ``enable_iwarp``
- Boolean
- Enable handling of iWARP traffic in the device.
* - ``internal_err_reset``
* - ``internal_error_reset``
- Boolean
- When enabled, the device driver will reset the device on internal
errors.

View File

@ -38,7 +38,7 @@ Devlink port flavours are described below.
- This indicates an eswitch port representing a port of PCI
subfunction (SF).
* - ``DEVLINK_PORT_FLAVOUR_VIRTUAL``
- This indicates a virtual port for the PCI virtual function.
- Any virtual port facing the user.
Devlink port can have a different type based on the link layer described below.
@ -134,6 +134,9 @@ Users may also set the IPsec crypto capability of the function using
Users may also set the IPsec packet capability of the function using
`devlink port function set ipsec_packet` command.
The ``migratable`` attribute may be set only on ports with
``DEVLINK_PORT_FLAVOUR_PCI_VF``.
Users may also set the maximum IO event queues of the function
using `devlink port function set max_io_eqs` command.

View File

@ -516,9 +516,11 @@ Generic Packet Trap Groups
Generic packet trap groups are used to aggregate logically related packet
traps. These groups allow the user to batch operations such as setting the trap
action of all member traps. In addition, ``devlink-trap`` can report aggregated
per-group packets and bytes statistics, in case per-trap statistics are too
narrow. The description of these groups must be added to the following table:
action of all member drop traps whose action may legally change. Exception and
control traps remain unchanged. In addition, ``devlink-trap`` can report
aggregated per-group packets and bytes statistics, in case per-trap statistics
are too narrow. The description of these groups must be added to the following
table:
.. list-table:: List of Generic Packet Trap Groups
:widths: 10 90

View File

@ -13,8 +13,8 @@ new APIs prefixed by ``devl_*``. The older APIs handle all the locking
in devlink core, but don't allow registration of most sub-objects once
the main devlink object is itself registered. The newer ``devl_*`` APIs assume
the devlink instance lock is already held. Drivers can take the instance
lock by calling ``devl_lock()``. It is also held all callbacks of devlink
netlink commands.
lock by calling ``devl_lock()``. It is also held across all callbacks of
devlink netlink commands.
Drivers are encouraged to use the devlink instance lock for their own needs.
@ -33,11 +33,11 @@ sure to respect following rules:
lock of both nested and parent instances at the same time, devlink
instance lock of the parent instance should be taken first, only then
instance lock of the nested instance could be taken.
- Driver should use object-specific helpers to setup the
nested relationship:
- Driver should use object-specific helpers to setup the nested relationship
before registering the nested devlink instance:
- ``devl_nested_devlink_set()`` - called to setup devlink -> nested
devlink relationship (could be user for multiple nested instances.
devlink relationship (could be used for multiple nested instances).
- ``devl_port_fn_devlink_set()`` - called to setup port function ->
nested devlink relationship.
- ``devlink_linecard_nested_dl_set()`` - called to setup linecard ->