2017-11-01 14:09:13 +00:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */
|
2016-02-26 16:32:23 +00:00
|
|
|
/*
|
|
|
|
|
* include/uapi/linux/devlink.h - Network physical device Netlink interface
|
|
|
|
|
* Copyright (c) 2016 Mellanox Technologies. All rights reserved.
|
|
|
|
|
* Copyright (c) 2016 Jiri Pirko <jiri@mellanox.com>
|
|
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
|
* (at your option) any later version.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef _UAPI_LINUX_DEVLINK_H_
|
|
|
|
|
#define _UAPI_LINUX_DEVLINK_H_
|
|
|
|
|
|
2020-09-29 18:08:59 +00:00
|
|
|
#include <linux/const.h>
|
|
|
|
|
|
2016-02-26 16:32:23 +00:00
|
|
|
#define DEVLINK_GENL_NAME "devlink"
|
|
|
|
|
#define DEVLINK_GENL_VERSION 0x1
|
|
|
|
|
#define DEVLINK_GENL_MCGRP_CONFIG_NAME "config"
|
|
|
|
|
|
|
|
|
|
enum devlink_command {
|
|
|
|
|
/* don't change the order or add anything between, this is ABI! */
|
|
|
|
|
DEVLINK_CMD_UNSPEC,
|
|
|
|
|
|
|
|
|
|
DEVLINK_CMD_GET, /* can dump */
|
|
|
|
|
DEVLINK_CMD_SET,
|
|
|
|
|
DEVLINK_CMD_NEW,
|
|
|
|
|
DEVLINK_CMD_DEL,
|
|
|
|
|
|
|
|
|
|
DEVLINK_CMD_PORT_GET, /* can dump */
|
|
|
|
|
DEVLINK_CMD_PORT_SET,
|
|
|
|
|
DEVLINK_CMD_PORT_NEW,
|
|
|
|
|
DEVLINK_CMD_PORT_DEL,
|
|
|
|
|
|
|
|
|
|
DEVLINK_CMD_PORT_SPLIT,
|
|
|
|
|
DEVLINK_CMD_PORT_UNSPLIT,
|
|
|
|
|
|
2016-04-14 16:19:13 +00:00
|
|
|
DEVLINK_CMD_SB_GET, /* can dump */
|
|
|
|
|
DEVLINK_CMD_SB_SET,
|
|
|
|
|
DEVLINK_CMD_SB_NEW,
|
|
|
|
|
DEVLINK_CMD_SB_DEL,
|
|
|
|
|
|
|
|
|
|
DEVLINK_CMD_SB_POOL_GET, /* can dump */
|
|
|
|
|
DEVLINK_CMD_SB_POOL_SET,
|
|
|
|
|
DEVLINK_CMD_SB_POOL_NEW,
|
|
|
|
|
DEVLINK_CMD_SB_POOL_DEL,
|
|
|
|
|
|
|
|
|
|
DEVLINK_CMD_SB_PORT_POOL_GET, /* can dump */
|
|
|
|
|
DEVLINK_CMD_SB_PORT_POOL_SET,
|
|
|
|
|
DEVLINK_CMD_SB_PORT_POOL_NEW,
|
|
|
|
|
DEVLINK_CMD_SB_PORT_POOL_DEL,
|
|
|
|
|
|
|
|
|
|
DEVLINK_CMD_SB_TC_POOL_BIND_GET, /* can dump */
|
|
|
|
|
DEVLINK_CMD_SB_TC_POOL_BIND_SET,
|
|
|
|
|
DEVLINK_CMD_SB_TC_POOL_BIND_NEW,
|
|
|
|
|
DEVLINK_CMD_SB_TC_POOL_BIND_DEL,
|
|
|
|
|
|
2016-04-14 16:19:14 +00:00
|
|
|
/* Shared buffer occupancy monitoring commands */
|
|
|
|
|
DEVLINK_CMD_SB_OCC_SNAPSHOT,
|
|
|
|
|
DEVLINK_CMD_SB_OCC_MAX_CLEAR,
|
|
|
|
|
|
2017-02-09 14:54:33 +00:00
|
|
|
DEVLINK_CMD_ESWITCH_GET,
|
|
|
|
|
#define DEVLINK_CMD_ESWITCH_MODE_GET /* obsolete, never use this! */ \
|
|
|
|
|
DEVLINK_CMD_ESWITCH_GET
|
|
|
|
|
|
|
|
|
|
DEVLINK_CMD_ESWITCH_SET,
|
|
|
|
|
#define DEVLINK_CMD_ESWITCH_MODE_SET /* obsolete, never use this! */ \
|
|
|
|
|
DEVLINK_CMD_ESWITCH_SET
|
|
|
|
|
|
2017-03-28 15:24:10 +00:00
|
|
|
DEVLINK_CMD_DPIPE_TABLE_GET,
|
|
|
|
|
DEVLINK_CMD_DPIPE_ENTRIES_GET,
|
|
|
|
|
DEVLINK_CMD_DPIPE_HEADERS_GET,
|
|
|
|
|
DEVLINK_CMD_DPIPE_TABLE_COUNTERS_SET,
|
2018-01-15 07:59:03 +00:00
|
|
|
DEVLINK_CMD_RESOURCE_SET,
|
|
|
|
|
DEVLINK_CMD_RESOURCE_DUMP,
|
2016-02-26 16:32:23 +00:00
|
|
|
|
2018-01-15 07:59:04 +00:00
|
|
|
/* Hot driver reload, makes configuration changes take place. The
|
|
|
|
|
* devlink instance is not released during the process.
|
|
|
|
|
*/
|
|
|
|
|
DEVLINK_CMD_RELOAD,
|
|
|
|
|
|
2018-07-04 11:30:29 +00:00
|
|
|
DEVLINK_CMD_PARAM_GET, /* can dump */
|
2018-07-04 11:30:30 +00:00
|
|
|
DEVLINK_CMD_PARAM_SET,
|
2018-07-04 11:30:32 +00:00
|
|
|
DEVLINK_CMD_PARAM_NEW,
|
|
|
|
|
DEVLINK_CMD_PARAM_DEL,
|
2018-07-04 11:30:29 +00:00
|
|
|
|
2018-07-12 12:13:11 +00:00
|
|
|
DEVLINK_CMD_REGION_GET,
|
|
|
|
|
DEVLINK_CMD_REGION_SET,
|
2018-07-12 12:13:13 +00:00
|
|
|
DEVLINK_CMD_REGION_NEW,
|
|
|
|
|
DEVLINK_CMD_REGION_DEL,
|
2018-07-12 12:13:14 +00:00
|
|
|
DEVLINK_CMD_REGION_READ,
|
2018-07-12 12:13:11 +00:00
|
|
|
|
2019-01-28 12:30:21 +00:00
|
|
|
DEVLINK_CMD_PORT_PARAM_GET, /* can dump */
|
2019-01-28 12:30:22 +00:00
|
|
|
DEVLINK_CMD_PORT_PARAM_SET,
|
2019-01-28 12:30:25 +00:00
|
|
|
DEVLINK_CMD_PORT_PARAM_NEW,
|
|
|
|
|
DEVLINK_CMD_PORT_PARAM_DEL,
|
2019-01-28 12:30:21 +00:00
|
|
|
|
2019-01-31 18:50:40 +00:00
|
|
|
DEVLINK_CMD_INFO_GET, /* can dump */
|
|
|
|
|
|
2019-02-07 09:36:35 +00:00
|
|
|
DEVLINK_CMD_HEALTH_REPORTER_GET,
|
2019-02-07 09:36:36 +00:00
|
|
|
DEVLINK_CMD_HEALTH_REPORTER_SET,
|
2019-02-07 09:36:37 +00:00
|
|
|
DEVLINK_CMD_HEALTH_REPORTER_RECOVER,
|
2019-02-07 09:36:38 +00:00
|
|
|
DEVLINK_CMD_HEALTH_REPORTER_DIAGNOSE,
|
2019-02-07 09:36:39 +00:00
|
|
|
DEVLINK_CMD_HEALTH_REPORTER_DUMP_GET,
|
|
|
|
|
DEVLINK_CMD_HEALTH_REPORTER_DUMP_CLEAR,
|
2019-02-07 09:36:35 +00:00
|
|
|
|
2019-02-14 21:40:44 +00:00
|
|
|
DEVLINK_CMD_FLASH_UPDATE,
|
2019-06-04 13:40:40 +00:00
|
|
|
DEVLINK_CMD_FLASH_UPDATE_END, /* notification only */
|
|
|
|
|
DEVLINK_CMD_FLASH_UPDATE_STATUS, /* notification only */
|
2019-02-14 21:40:44 +00:00
|
|
|
|
devlink: Add packet trap infrastructure
Add the basic packet trap infrastructure that allows device drivers to
register their supported packet traps and trap groups with devlink.
Each driver is expected to provide basic information about each
supported trap, such as name and ID, but also the supported metadata
types that will accompany each packet trapped via the trap. The
currently supported metadata type is just the input port, but more will
be added in the future. For example, output port and traffic class.
Trap groups allow users to set the action of all member traps. In
addition, users can retrieve per-group statistics in case per-trap
statistics are too narrow. In the future, the trap group object can be
extended with more attributes, such as policer settings which will limit
the amount of traffic generated by member traps towards the CPU.
Beside registering their packet traps with devlink, drivers are also
expected to report trapped packets to devlink along with relevant
metadata. devlink will maintain packets and bytes statistics for each
packet trap and will potentially report the trapped packet with its
metadata to user space via drop monitor netlink channel.
The interface towards the drivers is simple and allows devlink to set
the action of the trap. Currently, only two actions are supported:
'trap' and 'drop'. When set to 'trap', the device is expected to provide
the sole copy of the packet to the driver which will pass it to devlink.
When set to 'drop', the device is expected to drop the packet and not
send a copy to the driver. In the future, more actions can be added,
such as 'mirror'.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-17 13:28:17 +00:00
|
|
|
DEVLINK_CMD_TRAP_GET, /* can dump */
|
|
|
|
|
DEVLINK_CMD_TRAP_SET,
|
|
|
|
|
DEVLINK_CMD_TRAP_NEW,
|
|
|
|
|
DEVLINK_CMD_TRAP_DEL,
|
|
|
|
|
|
|
|
|
|
DEVLINK_CMD_TRAP_GROUP_GET, /* can dump */
|
|
|
|
|
DEVLINK_CMD_TRAP_GROUP_SET,
|
|
|
|
|
DEVLINK_CMD_TRAP_GROUP_NEW,
|
|
|
|
|
DEVLINK_CMD_TRAP_GROUP_DEL,
|
|
|
|
|
|
2020-03-30 19:38:18 +00:00
|
|
|
DEVLINK_CMD_TRAP_POLICER_GET, /* can dump */
|
|
|
|
|
DEVLINK_CMD_TRAP_POLICER_SET,
|
|
|
|
|
DEVLINK_CMD_TRAP_POLICER_NEW,
|
|
|
|
|
DEVLINK_CMD_TRAP_POLICER_DEL,
|
|
|
|
|
|
2020-09-15 08:40:57 +00:00
|
|
|
DEVLINK_CMD_HEALTH_REPORTER_TEST,
|
|
|
|
|
|
2021-06-02 12:17:19 +00:00
|
|
|
DEVLINK_CMD_RATE_GET, /* can dump */
|
|
|
|
|
DEVLINK_CMD_RATE_SET,
|
|
|
|
|
DEVLINK_CMD_RATE_NEW,
|
|
|
|
|
DEVLINK_CMD_RATE_DEL,
|
|
|
|
|
|
2022-04-18 06:42:25 +00:00
|
|
|
DEVLINK_CMD_LINECARD_GET, /* can dump */
|
|
|
|
|
DEVLINK_CMD_LINECARD_SET,
|
|
|
|
|
DEVLINK_CMD_LINECARD_NEW,
|
|
|
|
|
DEVLINK_CMD_LINECARD_DEL,
|
|
|
|
|
|
2022-07-27 16:57:20 +00:00
|
|
|
DEVLINK_CMD_SELFTESTS_GET, /* can dump */
|
|
|
|
|
DEVLINK_CMD_SELFTESTS_RUN,
|
|
|
|
|
|
2023-12-16 12:30:00 +00:00
|
|
|
DEVLINK_CMD_NOTIFY_FILTER_SET,
|
|
|
|
|
|
2017-03-28 15:24:10 +00:00
|
|
|
/* add new commands above here */
|
2016-02-26 16:32:23 +00:00
|
|
|
__DEVLINK_CMD_MAX,
|
|
|
|
|
DEVLINK_CMD_MAX = __DEVLINK_CMD_MAX - 1
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
enum devlink_port_type {
|
|
|
|
|
DEVLINK_PORT_TYPE_NOTSET,
|
|
|
|
|
DEVLINK_PORT_TYPE_AUTO,
|
|
|
|
|
DEVLINK_PORT_TYPE_ETH,
|
|
|
|
|
DEVLINK_PORT_TYPE_IB,
|
|
|
|
|
};
|
|
|
|
|
|
2016-04-14 16:19:13 +00:00
|
|
|
enum devlink_sb_pool_type {
|
|
|
|
|
DEVLINK_SB_POOL_TYPE_INGRESS,
|
|
|
|
|
DEVLINK_SB_POOL_TYPE_EGRESS,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* static threshold - limiting the maximum number of bytes.
|
|
|
|
|
* dynamic threshold - limiting the maximum number of bytes
|
|
|
|
|
* based on the currently available free space in the shared buffer pool.
|
|
|
|
|
* In this mode, the maximum quota is calculated based
|
|
|
|
|
* on the following formula:
|
|
|
|
|
* max_quota = alpha / (1 + alpha) * Free_Buffer
|
|
|
|
|
* While Free_Buffer is the amount of none-occupied buffer associated to
|
|
|
|
|
* the relevant pool.
|
|
|
|
|
* The value range which can be passed is 0-20 and serves
|
|
|
|
|
* for computation of alpha by following formula:
|
|
|
|
|
* alpha = 2 ^ (passed_value - 10)
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
enum devlink_sb_threshold_type {
|
|
|
|
|
DEVLINK_SB_THRESHOLD_TYPE_STATIC,
|
|
|
|
|
DEVLINK_SB_THRESHOLD_TYPE_DYNAMIC,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#define DEVLINK_SB_THRESHOLD_TO_ALPHA_MAX 20
|
|
|
|
|
|
2016-07-01 11:51:01 +00:00
|
|
|
enum devlink_eswitch_mode {
|
|
|
|
|
DEVLINK_ESWITCH_MODE_LEGACY,
|
|
|
|
|
DEVLINK_ESWITCH_MODE_SWITCHDEV,
|
|
|
|
|
};
|
|
|
|
|
|
2016-11-22 21:09:57 +00:00
|
|
|
enum devlink_eswitch_inline_mode {
|
|
|
|
|
DEVLINK_ESWITCH_INLINE_MODE_NONE,
|
|
|
|
|
DEVLINK_ESWITCH_INLINE_MODE_LINK,
|
|
|
|
|
DEVLINK_ESWITCH_INLINE_MODE_NETWORK,
|
|
|
|
|
DEVLINK_ESWITCH_INLINE_MODE_TRANSPORT,
|
|
|
|
|
};
|
|
|
|
|
|
2016-09-25 10:52:44 +00:00
|
|
|
enum devlink_eswitch_encap_mode {
|
|
|
|
|
DEVLINK_ESWITCH_ENCAP_MODE_NONE,
|
|
|
|
|
DEVLINK_ESWITCH_ENCAP_MODE_BASIC,
|
|
|
|
|
};
|
|
|
|
|
|
2018-05-18 07:29:01 +00:00
|
|
|
enum devlink_port_flavour {
|
|
|
|
|
DEVLINK_PORT_FLAVOUR_PHYSICAL, /* Any kind of a port physically
|
|
|
|
|
* facing the user.
|
|
|
|
|
*/
|
|
|
|
|
DEVLINK_PORT_FLAVOUR_CPU, /* CPU port */
|
|
|
|
|
DEVLINK_PORT_FLAVOUR_DSA, /* Distributed switch architecture
|
|
|
|
|
* interconnect port.
|
|
|
|
|
*/
|
2019-07-09 04:17:37 +00:00
|
|
|
DEVLINK_PORT_FLAVOUR_PCI_PF, /* Represents eswitch port for
|
|
|
|
|
* the PCI PF. It is an internal
|
|
|
|
|
* port that faces the PCI PF.
|
|
|
|
|
*/
|
2019-07-09 04:17:38 +00:00
|
|
|
DEVLINK_PORT_FLAVOUR_PCI_VF, /* Represents eswitch port
|
|
|
|
|
* for the PCI VF. It is an internal
|
|
|
|
|
* port that faces the PCI VF.
|
|
|
|
|
*/
|
2020-03-03 14:12:42 +00:00
|
|
|
DEVLINK_PORT_FLAVOUR_VIRTUAL, /* Any virtual port facing the user. */
|
2020-10-04 16:12:51 +00:00
|
|
|
DEVLINK_PORT_FLAVOUR_UNUSED, /* Port which exists in the switch, but
|
|
|
|
|
* is not used in any way.
|
|
|
|
|
*/
|
devlink: Introduce PCI SF port flavour and port attribute
A PCI sub-function (SF) represents a portion of the device similar
to PCI VF.
In an eswitch, PCI SF may have port which is normally represented
using a representor netdevice.
To have better visibility of eswitch port, its association with SF,
and its representor netdevice, introduce a PCI SF port flavour.
When devlink port flavour is PCI SF, fill up PCI SF attributes of the
port.
Extend port name creation using PCI PF and SF number scheme on best
effort basis, so that vendor drivers can skip defining their own
scheme.
This is done as cApfNSfM, where A, N and M are controller, PCI PF and
PCI SF number respectively.
This is similar to existing naming for PCI PF and PCI VF ports.
An example view of a PCI SF port:
$ devlink port show pci/0000:06:00.0/32768
pci/0000:06:00.0/32768: type eth netdev ens2f0npf0sf88 flavour pcisf controller 0 pfnum 0 sfnum 88 external false splittable false
function:
hw_addr 00:00:00:00:88:88 state active opstate attached
$ devlink port show pci/0000:06:00.0/32768 -jp
{
"port": {
"pci/0000:06:00.0/32768": {
"type": "eth",
"netdev": "ens2f0npf0sf88",
"flavour": "pcisf",
"controller": 0,
"pfnum": 0,
"sfnum": 88,
"splittable": false,
"function": {
"hw_addr": "00:00:00:00:88:88",
"state": "active",
"opstate": "attached"
}
}
}
}
Signed-off-by: Parav Pandit <parav@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Reviewed-by: Vu Pham <vuhuong@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-12-12 06:12:13 +00:00
|
|
|
DEVLINK_PORT_FLAVOUR_PCI_SF, /* Represents eswitch port
|
|
|
|
|
* for the PCI SF. It is an internal
|
|
|
|
|
* port that faces the PCI SF.
|
|
|
|
|
*/
|
2018-05-18 07:29:01 +00:00
|
|
|
};
|
|
|
|
|
|
2021-06-02 12:17:19 +00:00
|
|
|
enum devlink_rate_type {
|
|
|
|
|
DEVLINK_RATE_TYPE_LEAF,
|
2021-06-02 12:17:25 +00:00
|
|
|
DEVLINK_RATE_TYPE_NODE,
|
2021-06-02 12:17:19 +00:00
|
|
|
};
|
|
|
|
|
|
2018-07-04 11:30:28 +00:00
|
|
|
enum devlink_param_cmode {
|
|
|
|
|
DEVLINK_PARAM_CMODE_RUNTIME,
|
|
|
|
|
DEVLINK_PARAM_CMODE_DRIVERINIT,
|
|
|
|
|
DEVLINK_PARAM_CMODE_PERMANENT,
|
|
|
|
|
|
|
|
|
|
/* Add new configuration modes above */
|
|
|
|
|
__DEVLINK_PARAM_CMODE_MAX,
|
|
|
|
|
DEVLINK_PARAM_CMODE_MAX = __DEVLINK_PARAM_CMODE_MAX - 1
|
|
|
|
|
};
|
|
|
|
|
|
2018-12-03 07:58:59 +00:00
|
|
|
enum devlink_param_fw_load_policy_value {
|
|
|
|
|
DEVLINK_PARAM_FW_LOAD_POLICY_VALUE_DRIVER,
|
|
|
|
|
DEVLINK_PARAM_FW_LOAD_POLICY_VALUE_FLASH,
|
2019-09-08 23:54:17 +00:00
|
|
|
DEVLINK_PARAM_FW_LOAD_POLICY_VALUE_DISK,
|
2019-09-11 11:08:32 +00:00
|
|
|
DEVLINK_PARAM_FW_LOAD_POLICY_VALUE_UNKNOWN,
|
2018-12-03 07:58:59 +00:00
|
|
|
};
|
|
|
|
|
|
2019-09-08 23:54:18 +00:00
|
|
|
enum devlink_param_reset_dev_on_drv_probe_value {
|
|
|
|
|
DEVLINK_PARAM_RESET_DEV_ON_DRV_PROBE_VALUE_UNKNOWN,
|
|
|
|
|
DEVLINK_PARAM_RESET_DEV_ON_DRV_PROBE_VALUE_ALWAYS,
|
|
|
|
|
DEVLINK_PARAM_RESET_DEV_ON_DRV_PROBE_VALUE_NEVER,
|
|
|
|
|
DEVLINK_PARAM_RESET_DEV_ON_DRV_PROBE_VALUE_DISK,
|
|
|
|
|
};
|
|
|
|
|
|
devlink: Add packet trap infrastructure
Add the basic packet trap infrastructure that allows device drivers to
register their supported packet traps and trap groups with devlink.
Each driver is expected to provide basic information about each
supported trap, such as name and ID, but also the supported metadata
types that will accompany each packet trapped via the trap. The
currently supported metadata type is just the input port, but more will
be added in the future. For example, output port and traffic class.
Trap groups allow users to set the action of all member traps. In
addition, users can retrieve per-group statistics in case per-trap
statistics are too narrow. In the future, the trap group object can be
extended with more attributes, such as policer settings which will limit
the amount of traffic generated by member traps towards the CPU.
Beside registering their packet traps with devlink, drivers are also
expected to report trapped packets to devlink along with relevant
metadata. devlink will maintain packets and bytes statistics for each
packet trap and will potentially report the trapped packet with its
metadata to user space via drop monitor netlink channel.
The interface towards the drivers is simple and allows devlink to set
the action of the trap. Currently, only two actions are supported:
'trap' and 'drop'. When set to 'trap', the device is expected to provide
the sole copy of the packet to the driver which will pass it to devlink.
When set to 'drop', the device is expected to drop the packet and not
send a copy to the driver. In the future, more actions can be added,
such as 'mirror'.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-17 13:28:17 +00:00
|
|
|
enum {
|
|
|
|
|
DEVLINK_ATTR_STATS_RX_PACKETS, /* u64 */
|
|
|
|
|
DEVLINK_ATTR_STATS_RX_BYTES, /* u64 */
|
2020-03-30 19:38:18 +00:00
|
|
|
DEVLINK_ATTR_STATS_RX_DROPPED, /* u64 */
|
devlink: Add packet trap infrastructure
Add the basic packet trap infrastructure that allows device drivers to
register their supported packet traps and trap groups with devlink.
Each driver is expected to provide basic information about each
supported trap, such as name and ID, but also the supported metadata
types that will accompany each packet trapped via the trap. The
currently supported metadata type is just the input port, but more will
be added in the future. For example, output port and traffic class.
Trap groups allow users to set the action of all member traps. In
addition, users can retrieve per-group statistics in case per-trap
statistics are too narrow. In the future, the trap group object can be
extended with more attributes, such as policer settings which will limit
the amount of traffic generated by member traps towards the CPU.
Beside registering their packet traps with devlink, drivers are also
expected to report trapped packets to devlink along with relevant
metadata. devlink will maintain packets and bytes statistics for each
packet trap and will potentially report the trapped packet with its
metadata to user space via drop monitor netlink channel.
The interface towards the drivers is simple and allows devlink to set
the action of the trap. Currently, only two actions are supported:
'trap' and 'drop'. When set to 'trap', the device is expected to provide
the sole copy of the packet to the driver which will pass it to devlink.
When set to 'drop', the device is expected to drop the packet and not
send a copy to the driver. In the future, more actions can be added,
such as 'mirror'.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-17 13:28:17 +00:00
|
|
|
|
|
|
|
|
__DEVLINK_ATTR_STATS_MAX,
|
|
|
|
|
DEVLINK_ATTR_STATS_MAX = __DEVLINK_ATTR_STATS_MAX - 1
|
|
|
|
|
};
|
|
|
|
|
|
devlink: introduce flash update overwrite mask
Sections of device flash may contain settings or device identifying
information. When performing a flash update, it is generally expected
that these settings and identifiers are not overwritten.
However, it may sometimes be useful to allow overwriting these fields
when performing a flash update. Some examples include, 1) customizing
the initial device config on first programming, such as overwriting
default device identifying information, or 2) reverting a device
configuration to known good state provided in the new firmware image, or
3) in case it is suspected that current firmware logic for managing the
preservation of fields during an update is broken.
Although some devices are able to completely separate these types of
settings and fields into separate components, this is not true for all
hardware.
To support controlling this behavior, a new
DEVLINK_ATTR_FLASH_UPDATE_OVERWRITE_MASK is defined. This is an
nla_bitfield32 which will define what subset of fields in a component
should be overwritten during an update.
If no bits are specified, or of the overwrite mask is not provided, then
an update should not overwrite anything, and should maintain the
settings and identifiers as they are in the previous image.
If the overwrite mask has the DEVLINK_FLASH_OVERWRITE_SETTINGS bit set,
then the device should be configured to overwrite any of the settings in
the requested component with settings found in the provided image.
Similarly, if the DEVLINK_FLASH_OVERWRITE_IDENTIFIERS bit is set, the
device should be configured to overwrite any device identifiers in the
requested component with the identifiers from the image.
Multiple overwrite modes may be combined to indicate that a combination
of the set of fields that should be overwritten.
Drivers which support the new overwrite mask must set the
DEVLINK_SUPPORT_FLASH_UPDATE_OVERWRITE_MASK in the
supported_flash_update_params field of their devlink_ops.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-25 20:46:07 +00:00
|
|
|
/* Specify what sections of a flash component can be overwritten when
|
|
|
|
|
* performing an update. Overwriting of firmware binary sections is always
|
|
|
|
|
* implicitly assumed to be allowed.
|
|
|
|
|
*
|
|
|
|
|
* Each section must be documented in
|
|
|
|
|
* Documentation/networking/devlink/devlink-flash.rst
|
|
|
|
|
*
|
|
|
|
|
*/
|
2023-10-21 11:27:07 +00:00
|
|
|
enum devlink_flash_overwrite {
|
devlink: introduce flash update overwrite mask
Sections of device flash may contain settings or device identifying
information. When performing a flash update, it is generally expected
that these settings and identifiers are not overwritten.
However, it may sometimes be useful to allow overwriting these fields
when performing a flash update. Some examples include, 1) customizing
the initial device config on first programming, such as overwriting
default device identifying information, or 2) reverting a device
configuration to known good state provided in the new firmware image, or
3) in case it is suspected that current firmware logic for managing the
preservation of fields during an update is broken.
Although some devices are able to completely separate these types of
settings and fields into separate components, this is not true for all
hardware.
To support controlling this behavior, a new
DEVLINK_ATTR_FLASH_UPDATE_OVERWRITE_MASK is defined. This is an
nla_bitfield32 which will define what subset of fields in a component
should be overwritten during an update.
If no bits are specified, or of the overwrite mask is not provided, then
an update should not overwrite anything, and should maintain the
settings and identifiers as they are in the previous image.
If the overwrite mask has the DEVLINK_FLASH_OVERWRITE_SETTINGS bit set,
then the device should be configured to overwrite any of the settings in
the requested component with settings found in the provided image.
Similarly, if the DEVLINK_FLASH_OVERWRITE_IDENTIFIERS bit is set, the
device should be configured to overwrite any device identifiers in the
requested component with the identifiers from the image.
Multiple overwrite modes may be combined to indicate that a combination
of the set of fields that should be overwritten.
Drivers which support the new overwrite mask must set the
DEVLINK_SUPPORT_FLASH_UPDATE_OVERWRITE_MASK in the
supported_flash_update_params field of their devlink_ops.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-25 20:46:07 +00:00
|
|
|
DEVLINK_FLASH_OVERWRITE_SETTINGS_BIT,
|
|
|
|
|
DEVLINK_FLASH_OVERWRITE_IDENTIFIERS_BIT,
|
|
|
|
|
|
|
|
|
|
__DEVLINK_FLASH_OVERWRITE_MAX_BIT,
|
|
|
|
|
DEVLINK_FLASH_OVERWRITE_MAX_BIT = __DEVLINK_FLASH_OVERWRITE_MAX_BIT - 1
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#define DEVLINK_FLASH_OVERWRITE_SETTINGS _BITUL(DEVLINK_FLASH_OVERWRITE_SETTINGS_BIT)
|
|
|
|
|
#define DEVLINK_FLASH_OVERWRITE_IDENTIFIERS _BITUL(DEVLINK_FLASH_OVERWRITE_IDENTIFIERS_BIT)
|
|
|
|
|
|
|
|
|
|
#define DEVLINK_SUPPORTED_FLASH_OVERWRITE_SECTIONS \
|
|
|
|
|
(_BITUL(__DEVLINK_FLASH_OVERWRITE_MAX_BIT) - 1)
|
|
|
|
|
|
2022-07-27 16:57:20 +00:00
|
|
|
enum devlink_attr_selftest_id {
|
|
|
|
|
DEVLINK_ATTR_SELFTEST_ID_UNSPEC,
|
|
|
|
|
DEVLINK_ATTR_SELFTEST_ID_FLASH, /* flag */
|
|
|
|
|
|
|
|
|
|
__DEVLINK_ATTR_SELFTEST_ID_MAX,
|
|
|
|
|
DEVLINK_ATTR_SELFTEST_ID_MAX = __DEVLINK_ATTR_SELFTEST_ID_MAX - 1
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
enum devlink_selftest_status {
|
|
|
|
|
DEVLINK_SELFTEST_STATUS_SKIP,
|
|
|
|
|
DEVLINK_SELFTEST_STATUS_PASS,
|
|
|
|
|
DEVLINK_SELFTEST_STATUS_FAIL
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
enum devlink_attr_selftest_result {
|
|
|
|
|
DEVLINK_ATTR_SELFTEST_RESULT_UNSPEC,
|
|
|
|
|
DEVLINK_ATTR_SELFTEST_RESULT, /* nested */
|
|
|
|
|
DEVLINK_ATTR_SELFTEST_RESULT_ID, /* u32, enum devlink_attr_selftest_id */
|
|
|
|
|
DEVLINK_ATTR_SELFTEST_RESULT_STATUS, /* u8, enum devlink_selftest_status */
|
|
|
|
|
|
|
|
|
|
__DEVLINK_ATTR_SELFTEST_RESULT_MAX,
|
|
|
|
|
DEVLINK_ATTR_SELFTEST_RESULT_MAX = __DEVLINK_ATTR_SELFTEST_RESULT_MAX - 1
|
|
|
|
|
};
|
|
|
|
|
|
devlink: Add packet trap infrastructure
Add the basic packet trap infrastructure that allows device drivers to
register their supported packet traps and trap groups with devlink.
Each driver is expected to provide basic information about each
supported trap, such as name and ID, but also the supported metadata
types that will accompany each packet trapped via the trap. The
currently supported metadata type is just the input port, but more will
be added in the future. For example, output port and traffic class.
Trap groups allow users to set the action of all member traps. In
addition, users can retrieve per-group statistics in case per-trap
statistics are too narrow. In the future, the trap group object can be
extended with more attributes, such as policer settings which will limit
the amount of traffic generated by member traps towards the CPU.
Beside registering their packet traps with devlink, drivers are also
expected to report trapped packets to devlink along with relevant
metadata. devlink will maintain packets and bytes statistics for each
packet trap and will potentially report the trapped packet with its
metadata to user space via drop monitor netlink channel.
The interface towards the drivers is simple and allows devlink to set
the action of the trap. Currently, only two actions are supported:
'trap' and 'drop'. When set to 'trap', the device is expected to provide
the sole copy of the packet to the driver which will pass it to devlink.
When set to 'drop', the device is expected to drop the packet and not
send a copy to the driver. In the future, more actions can be added,
such as 'mirror'.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-17 13:28:17 +00:00
|
|
|
/**
|
|
|
|
|
* enum devlink_trap_action - Packet trap action.
|
|
|
|
|
* @DEVLINK_TRAP_ACTION_DROP: Packet is dropped by the device and a copy is not
|
|
|
|
|
* sent to the CPU.
|
|
|
|
|
* @DEVLINK_TRAP_ACTION_TRAP: The sole copy of the packet is sent to the CPU.
|
2020-05-29 18:36:39 +00:00
|
|
|
* @DEVLINK_TRAP_ACTION_MIRROR: Packet is forwarded by the device and a copy is
|
|
|
|
|
* sent to the CPU.
|
devlink: Add packet trap infrastructure
Add the basic packet trap infrastructure that allows device drivers to
register their supported packet traps and trap groups with devlink.
Each driver is expected to provide basic information about each
supported trap, such as name and ID, but also the supported metadata
types that will accompany each packet trapped via the trap. The
currently supported metadata type is just the input port, but more will
be added in the future. For example, output port and traffic class.
Trap groups allow users to set the action of all member traps. In
addition, users can retrieve per-group statistics in case per-trap
statistics are too narrow. In the future, the trap group object can be
extended with more attributes, such as policer settings which will limit
the amount of traffic generated by member traps towards the CPU.
Beside registering their packet traps with devlink, drivers are also
expected to report trapped packets to devlink along with relevant
metadata. devlink will maintain packets and bytes statistics for each
packet trap and will potentially report the trapped packet with its
metadata to user space via drop monitor netlink channel.
The interface towards the drivers is simple and allows devlink to set
the action of the trap. Currently, only two actions are supported:
'trap' and 'drop'. When set to 'trap', the device is expected to provide
the sole copy of the packet to the driver which will pass it to devlink.
When set to 'drop', the device is expected to drop the packet and not
send a copy to the driver. In the future, more actions can be added,
such as 'mirror'.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-17 13:28:17 +00:00
|
|
|
*/
|
|
|
|
|
enum devlink_trap_action {
|
|
|
|
|
DEVLINK_TRAP_ACTION_DROP,
|
|
|
|
|
DEVLINK_TRAP_ACTION_TRAP,
|
2020-05-29 18:36:39 +00:00
|
|
|
DEVLINK_TRAP_ACTION_MIRROR,
|
devlink: Add packet trap infrastructure
Add the basic packet trap infrastructure that allows device drivers to
register their supported packet traps and trap groups with devlink.
Each driver is expected to provide basic information about each
supported trap, such as name and ID, but also the supported metadata
types that will accompany each packet trapped via the trap. The
currently supported metadata type is just the input port, but more will
be added in the future. For example, output port and traffic class.
Trap groups allow users to set the action of all member traps. In
addition, users can retrieve per-group statistics in case per-trap
statistics are too narrow. In the future, the trap group object can be
extended with more attributes, such as policer settings which will limit
the amount of traffic generated by member traps towards the CPU.
Beside registering their packet traps with devlink, drivers are also
expected to report trapped packets to devlink along with relevant
metadata. devlink will maintain packets and bytes statistics for each
packet trap and will potentially report the trapped packet with its
metadata to user space via drop monitor netlink channel.
The interface towards the drivers is simple and allows devlink to set
the action of the trap. Currently, only two actions are supported:
'trap' and 'drop'. When set to 'trap', the device is expected to provide
the sole copy of the packet to the driver which will pass it to devlink.
When set to 'drop', the device is expected to drop the packet and not
send a copy to the driver. In the future, more actions can be added,
such as 'mirror'.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-17 13:28:17 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* enum devlink_trap_type - Packet trap type.
|
|
|
|
|
* @DEVLINK_TRAP_TYPE_DROP: Trap reason is a drop. Trapped packets are only
|
|
|
|
|
* processed by devlink and not injected to the
|
|
|
|
|
* kernel's Rx path.
|
|
|
|
|
* @DEVLINK_TRAP_TYPE_EXCEPTION: Trap reason is an exception. Packet was not
|
|
|
|
|
* forwarded as intended due to an exception
|
|
|
|
|
* (e.g., missing neighbour entry) and trapped to
|
|
|
|
|
* control plane for resolution. Trapped packets
|
|
|
|
|
* are processed by devlink and injected to
|
|
|
|
|
* the kernel's Rx path.
|
2020-05-29 18:36:40 +00:00
|
|
|
* @DEVLINK_TRAP_TYPE_CONTROL: Packet was trapped because it is required for
|
|
|
|
|
* the correct functioning of the control plane.
|
|
|
|
|
* For example, an ARP request packet. Trapped
|
|
|
|
|
* packets are injected to the kernel's Rx path,
|
|
|
|
|
* but not reported to drop monitor.
|
devlink: Add packet trap infrastructure
Add the basic packet trap infrastructure that allows device drivers to
register their supported packet traps and trap groups with devlink.
Each driver is expected to provide basic information about each
supported trap, such as name and ID, but also the supported metadata
types that will accompany each packet trapped via the trap. The
currently supported metadata type is just the input port, but more will
be added in the future. For example, output port and traffic class.
Trap groups allow users to set the action of all member traps. In
addition, users can retrieve per-group statistics in case per-trap
statistics are too narrow. In the future, the trap group object can be
extended with more attributes, such as policer settings which will limit
the amount of traffic generated by member traps towards the CPU.
Beside registering their packet traps with devlink, drivers are also
expected to report trapped packets to devlink along with relevant
metadata. devlink will maintain packets and bytes statistics for each
packet trap and will potentially report the trapped packet with its
metadata to user space via drop monitor netlink channel.
The interface towards the drivers is simple and allows devlink to set
the action of the trap. Currently, only two actions are supported:
'trap' and 'drop'. When set to 'trap', the device is expected to provide
the sole copy of the packet to the driver which will pass it to devlink.
When set to 'drop', the device is expected to drop the packet and not
send a copy to the driver. In the future, more actions can be added,
such as 'mirror'.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-17 13:28:17 +00:00
|
|
|
*/
|
|
|
|
|
enum devlink_trap_type {
|
|
|
|
|
DEVLINK_TRAP_TYPE_DROP,
|
|
|
|
|
DEVLINK_TRAP_TYPE_EXCEPTION,
|
2020-05-29 18:36:40 +00:00
|
|
|
DEVLINK_TRAP_TYPE_CONTROL,
|
devlink: Add packet trap infrastructure
Add the basic packet trap infrastructure that allows device drivers to
register their supported packet traps and trap groups with devlink.
Each driver is expected to provide basic information about each
supported trap, such as name and ID, but also the supported metadata
types that will accompany each packet trapped via the trap. The
currently supported metadata type is just the input port, but more will
be added in the future. For example, output port and traffic class.
Trap groups allow users to set the action of all member traps. In
addition, users can retrieve per-group statistics in case per-trap
statistics are too narrow. In the future, the trap group object can be
extended with more attributes, such as policer settings which will limit
the amount of traffic generated by member traps towards the CPU.
Beside registering their packet traps with devlink, drivers are also
expected to report trapped packets to devlink along with relevant
metadata. devlink will maintain packets and bytes statistics for each
packet trap and will potentially report the trapped packet with its
metadata to user space via drop monitor netlink channel.
The interface towards the drivers is simple and allows devlink to set
the action of the trap. Currently, only two actions are supported:
'trap' and 'drop'. When set to 'trap', the device is expected to provide
the sole copy of the packet to the driver which will pass it to devlink.
When set to 'drop', the device is expected to drop the packet and not
send a copy to the driver. In the future, more actions can be added,
such as 'mirror'.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-17 13:28:17 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
enum {
|
|
|
|
|
/* Trap can report input port as metadata */
|
|
|
|
|
DEVLINK_ATTR_TRAP_METADATA_TYPE_IN_PORT,
|
2020-02-25 10:45:19 +00:00
|
|
|
/* Trap can report flow action cookie as metadata */
|
|
|
|
|
DEVLINK_ATTR_TRAP_METADATA_TYPE_FA_COOKIE,
|
devlink: Add packet trap infrastructure
Add the basic packet trap infrastructure that allows device drivers to
register their supported packet traps and trap groups with devlink.
Each driver is expected to provide basic information about each
supported trap, such as name and ID, but also the supported metadata
types that will accompany each packet trapped via the trap. The
currently supported metadata type is just the input port, but more will
be added in the future. For example, output port and traffic class.
Trap groups allow users to set the action of all member traps. In
addition, users can retrieve per-group statistics in case per-trap
statistics are too narrow. In the future, the trap group object can be
extended with more attributes, such as policer settings which will limit
the amount of traffic generated by member traps towards the CPU.
Beside registering their packet traps with devlink, drivers are also
expected to report trapped packets to devlink along with relevant
metadata. devlink will maintain packets and bytes statistics for each
packet trap and will potentially report the trapped packet with its
metadata to user space via drop monitor netlink channel.
The interface towards the drivers is simple and allows devlink to set
the action of the trap. Currently, only two actions are supported:
'trap' and 'drop'. When set to 'trap', the device is expected to provide
the sole copy of the packet to the driver which will pass it to devlink.
When set to 'drop', the device is expected to drop the packet and not
send a copy to the driver. In the future, more actions can be added,
such as 'mirror'.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-17 13:28:17 +00:00
|
|
|
};
|
|
|
|
|
|
2020-10-07 06:00:43 +00:00
|
|
|
enum devlink_reload_action {
|
|
|
|
|
DEVLINK_RELOAD_ACTION_UNSPEC,
|
|
|
|
|
DEVLINK_RELOAD_ACTION_DRIVER_REINIT, /* Driver entities re-instantiation */
|
|
|
|
|
DEVLINK_RELOAD_ACTION_FW_ACTIVATE, /* FW activate */
|
|
|
|
|
|
|
|
|
|
/* Add new reload actions above */
|
|
|
|
|
__DEVLINK_RELOAD_ACTION_MAX,
|
|
|
|
|
DEVLINK_RELOAD_ACTION_MAX = __DEVLINK_RELOAD_ACTION_MAX - 1
|
|
|
|
|
};
|
|
|
|
|
|
2020-10-07 06:00:44 +00:00
|
|
|
enum devlink_reload_limit {
|
|
|
|
|
DEVLINK_RELOAD_LIMIT_UNSPEC, /* unspecified, no constraints */
|
|
|
|
|
DEVLINK_RELOAD_LIMIT_NO_RESET, /* No reset allowed, no down time allowed,
|
|
|
|
|
* no link flap and no configuration is lost.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/* Add new reload limit above */
|
|
|
|
|
__DEVLINK_RELOAD_LIMIT_MAX,
|
|
|
|
|
DEVLINK_RELOAD_LIMIT_MAX = __DEVLINK_RELOAD_LIMIT_MAX - 1
|
|
|
|
|
};
|
|
|
|
|
|
2020-12-15 10:25:31 +00:00
|
|
|
#define DEVLINK_RELOAD_LIMITS_VALID_MASK (_BITUL(__DEVLINK_RELOAD_LIMIT_MAX) - 1)
|
2020-10-07 06:00:44 +00:00
|
|
|
|
2022-04-18 06:42:26 +00:00
|
|
|
enum devlink_linecard_state {
|
|
|
|
|
DEVLINK_LINECARD_STATE_UNSPEC,
|
|
|
|
|
DEVLINK_LINECARD_STATE_UNPROVISIONED,
|
|
|
|
|
DEVLINK_LINECARD_STATE_UNPROVISIONING,
|
|
|
|
|
DEVLINK_LINECARD_STATE_PROVISIONING,
|
|
|
|
|
DEVLINK_LINECARD_STATE_PROVISIONING_FAILED,
|
|
|
|
|
DEVLINK_LINECARD_STATE_PROVISIONED,
|
2022-04-18 06:42:27 +00:00
|
|
|
DEVLINK_LINECARD_STATE_ACTIVE,
|
2022-04-18 06:42:26 +00:00
|
|
|
|
|
|
|
|
__DEVLINK_LINECARD_STATE_MAX,
|
|
|
|
|
DEVLINK_LINECARD_STATE_MAX = __DEVLINK_LINECARD_STATE_MAX - 1
|
|
|
|
|
};
|
|
|
|
|
|
2016-02-26 16:32:23 +00:00
|
|
|
enum devlink_attr {
|
|
|
|
|
/* don't change the order or add anything between, this is ABI! */
|
|
|
|
|
DEVLINK_ATTR_UNSPEC,
|
|
|
|
|
|
|
|
|
|
/* bus name + dev name together are a handle for devlink entity */
|
|
|
|
|
DEVLINK_ATTR_BUS_NAME, /* string */
|
|
|
|
|
DEVLINK_ATTR_DEV_NAME, /* string */
|
|
|
|
|
|
|
|
|
|
DEVLINK_ATTR_PORT_INDEX, /* u32 */
|
|
|
|
|
DEVLINK_ATTR_PORT_TYPE, /* u16 */
|
|
|
|
|
DEVLINK_ATTR_PORT_DESIRED_TYPE, /* u16 */
|
|
|
|
|
DEVLINK_ATTR_PORT_NETDEV_IFINDEX, /* u32 */
|
|
|
|
|
DEVLINK_ATTR_PORT_NETDEV_NAME, /* string */
|
|
|
|
|
DEVLINK_ATTR_PORT_IBDEV_NAME, /* string */
|
|
|
|
|
DEVLINK_ATTR_PORT_SPLIT_COUNT, /* u32 */
|
|
|
|
|
DEVLINK_ATTR_PORT_SPLIT_GROUP, /* u32 */
|
2016-04-14 16:19:13 +00:00
|
|
|
DEVLINK_ATTR_SB_INDEX, /* u32 */
|
|
|
|
|
DEVLINK_ATTR_SB_SIZE, /* u32 */
|
|
|
|
|
DEVLINK_ATTR_SB_INGRESS_POOL_COUNT, /* u16 */
|
|
|
|
|
DEVLINK_ATTR_SB_EGRESS_POOL_COUNT, /* u16 */
|
|
|
|
|
DEVLINK_ATTR_SB_INGRESS_TC_COUNT, /* u16 */
|
|
|
|
|
DEVLINK_ATTR_SB_EGRESS_TC_COUNT, /* u16 */
|
|
|
|
|
DEVLINK_ATTR_SB_POOL_INDEX, /* u16 */
|
|
|
|
|
DEVLINK_ATTR_SB_POOL_TYPE, /* u8 */
|
|
|
|
|
DEVLINK_ATTR_SB_POOL_SIZE, /* u32 */
|
|
|
|
|
DEVLINK_ATTR_SB_POOL_THRESHOLD_TYPE, /* u8 */
|
|
|
|
|
DEVLINK_ATTR_SB_THRESHOLD, /* u32 */
|
|
|
|
|
DEVLINK_ATTR_SB_TC_INDEX, /* u16 */
|
2016-04-14 16:19:14 +00:00
|
|
|
DEVLINK_ATTR_SB_OCC_CUR, /* u32 */
|
|
|
|
|
DEVLINK_ATTR_SB_OCC_MAX, /* u32 */
|
2016-07-01 11:51:01 +00:00
|
|
|
DEVLINK_ATTR_ESWITCH_MODE, /* u16 */
|
2016-11-22 21:09:57 +00:00
|
|
|
DEVLINK_ATTR_ESWITCH_INLINE_MODE, /* u8 */
|
2016-02-26 16:32:23 +00:00
|
|
|
|
2017-03-28 15:24:10 +00:00
|
|
|
DEVLINK_ATTR_DPIPE_TABLES, /* nested */
|
|
|
|
|
DEVLINK_ATTR_DPIPE_TABLE, /* nested */
|
|
|
|
|
DEVLINK_ATTR_DPIPE_TABLE_NAME, /* string */
|
|
|
|
|
DEVLINK_ATTR_DPIPE_TABLE_SIZE, /* u64 */
|
|
|
|
|
DEVLINK_ATTR_DPIPE_TABLE_MATCHES, /* nested */
|
|
|
|
|
DEVLINK_ATTR_DPIPE_TABLE_ACTIONS, /* nested */
|
|
|
|
|
DEVLINK_ATTR_DPIPE_TABLE_COUNTERS_ENABLED, /* u8 */
|
|
|
|
|
|
|
|
|
|
DEVLINK_ATTR_DPIPE_ENTRIES, /* nested */
|
|
|
|
|
DEVLINK_ATTR_DPIPE_ENTRY, /* nested */
|
|
|
|
|
DEVLINK_ATTR_DPIPE_ENTRY_INDEX, /* u64 */
|
|
|
|
|
DEVLINK_ATTR_DPIPE_ENTRY_MATCH_VALUES, /* nested */
|
|
|
|
|
DEVLINK_ATTR_DPIPE_ENTRY_ACTION_VALUES, /* nested */
|
|
|
|
|
DEVLINK_ATTR_DPIPE_ENTRY_COUNTER, /* u64 */
|
|
|
|
|
|
|
|
|
|
DEVLINK_ATTR_DPIPE_MATCH, /* nested */
|
|
|
|
|
DEVLINK_ATTR_DPIPE_MATCH_VALUE, /* nested */
|
|
|
|
|
DEVLINK_ATTR_DPIPE_MATCH_TYPE, /* u32 */
|
|
|
|
|
|
|
|
|
|
DEVLINK_ATTR_DPIPE_ACTION, /* nested */
|
|
|
|
|
DEVLINK_ATTR_DPIPE_ACTION_VALUE, /* nested */
|
|
|
|
|
DEVLINK_ATTR_DPIPE_ACTION_TYPE, /* u32 */
|
|
|
|
|
|
|
|
|
|
DEVLINK_ATTR_DPIPE_VALUE,
|
|
|
|
|
DEVLINK_ATTR_DPIPE_VALUE_MASK,
|
|
|
|
|
DEVLINK_ATTR_DPIPE_VALUE_MAPPING, /* u32 */
|
|
|
|
|
|
|
|
|
|
DEVLINK_ATTR_DPIPE_HEADERS, /* nested */
|
|
|
|
|
DEVLINK_ATTR_DPIPE_HEADER, /* nested */
|
|
|
|
|
DEVLINK_ATTR_DPIPE_HEADER_NAME, /* string */
|
|
|
|
|
DEVLINK_ATTR_DPIPE_HEADER_ID, /* u32 */
|
|
|
|
|
DEVLINK_ATTR_DPIPE_HEADER_FIELDS, /* nested */
|
|
|
|
|
DEVLINK_ATTR_DPIPE_HEADER_GLOBAL, /* u8 */
|
|
|
|
|
DEVLINK_ATTR_DPIPE_HEADER_INDEX, /* u32 */
|
|
|
|
|
|
|
|
|
|
DEVLINK_ATTR_DPIPE_FIELD, /* nested */
|
|
|
|
|
DEVLINK_ATTR_DPIPE_FIELD_NAME, /* string */
|
|
|
|
|
DEVLINK_ATTR_DPIPE_FIELD_ID, /* u32 */
|
|
|
|
|
DEVLINK_ATTR_DPIPE_FIELD_BITWIDTH, /* u32 */
|
|
|
|
|
DEVLINK_ATTR_DPIPE_FIELD_MAPPING_TYPE, /* u32 */
|
|
|
|
|
|
|
|
|
|
DEVLINK_ATTR_PAD,
|
|
|
|
|
|
2016-09-25 10:52:44 +00:00
|
|
|
DEVLINK_ATTR_ESWITCH_ENCAP_MODE, /* u8 */
|
2018-01-15 07:59:03 +00:00
|
|
|
DEVLINK_ATTR_RESOURCE_LIST, /* nested */
|
|
|
|
|
DEVLINK_ATTR_RESOURCE, /* nested */
|
|
|
|
|
DEVLINK_ATTR_RESOURCE_NAME, /* string */
|
|
|
|
|
DEVLINK_ATTR_RESOURCE_ID, /* u64 */
|
|
|
|
|
DEVLINK_ATTR_RESOURCE_SIZE, /* u64 */
|
|
|
|
|
DEVLINK_ATTR_RESOURCE_SIZE_NEW, /* u64 */
|
|
|
|
|
DEVLINK_ATTR_RESOURCE_SIZE_VALID, /* u8 */
|
|
|
|
|
DEVLINK_ATTR_RESOURCE_SIZE_MIN, /* u64 */
|
|
|
|
|
DEVLINK_ATTR_RESOURCE_SIZE_MAX, /* u64 */
|
|
|
|
|
DEVLINK_ATTR_RESOURCE_SIZE_GRAN, /* u64 */
|
|
|
|
|
DEVLINK_ATTR_RESOURCE_UNIT, /* u8 */
|
|
|
|
|
DEVLINK_ATTR_RESOURCE_OCC, /* u64 */
|
2018-01-15 07:59:05 +00:00
|
|
|
DEVLINK_ATTR_DPIPE_TABLE_RESOURCE_ID, /* u64 */
|
|
|
|
|
DEVLINK_ATTR_DPIPE_TABLE_RESOURCE_UNITS,/* u64 */
|
2016-09-25 10:52:44 +00:00
|
|
|
|
2018-05-18 07:29:01 +00:00
|
|
|
DEVLINK_ATTR_PORT_FLAVOUR, /* u16 */
|
2018-05-18 07:29:00 +00:00
|
|
|
DEVLINK_ATTR_PORT_NUMBER, /* u32 */
|
|
|
|
|
DEVLINK_ATTR_PORT_SPLIT_SUBPORT_NUMBER, /* u32 */
|
|
|
|
|
|
2018-07-04 11:30:29 +00:00
|
|
|
DEVLINK_ATTR_PARAM, /* nested */
|
|
|
|
|
DEVLINK_ATTR_PARAM_NAME, /* string */
|
|
|
|
|
DEVLINK_ATTR_PARAM_GENERIC, /* flag */
|
|
|
|
|
DEVLINK_ATTR_PARAM_TYPE, /* u8 */
|
|
|
|
|
DEVLINK_ATTR_PARAM_VALUES_LIST, /* nested */
|
|
|
|
|
DEVLINK_ATTR_PARAM_VALUE, /* nested */
|
|
|
|
|
DEVLINK_ATTR_PARAM_VALUE_DATA, /* dynamic */
|
|
|
|
|
DEVLINK_ATTR_PARAM_VALUE_CMODE, /* u8 */
|
|
|
|
|
|
2018-07-12 12:13:11 +00:00
|
|
|
DEVLINK_ATTR_REGION_NAME, /* string */
|
|
|
|
|
DEVLINK_ATTR_REGION_SIZE, /* u64 */
|
2018-07-12 12:13:12 +00:00
|
|
|
DEVLINK_ATTR_REGION_SNAPSHOTS, /* nested */
|
|
|
|
|
DEVLINK_ATTR_REGION_SNAPSHOT, /* nested */
|
|
|
|
|
DEVLINK_ATTR_REGION_SNAPSHOT_ID, /* u32 */
|
2018-07-12 12:13:11 +00:00
|
|
|
|
2018-07-12 12:13:14 +00:00
|
|
|
DEVLINK_ATTR_REGION_CHUNKS, /* nested */
|
|
|
|
|
DEVLINK_ATTR_REGION_CHUNK, /* nested */
|
|
|
|
|
DEVLINK_ATTR_REGION_CHUNK_DATA, /* binary */
|
|
|
|
|
DEVLINK_ATTR_REGION_CHUNK_ADDR, /* u64 */
|
|
|
|
|
DEVLINK_ATTR_REGION_CHUNK_LEN, /* u64 */
|
|
|
|
|
|
2019-01-31 18:50:40 +00:00
|
|
|
DEVLINK_ATTR_INFO_DRIVER_NAME, /* string */
|
|
|
|
|
DEVLINK_ATTR_INFO_SERIAL_NUMBER, /* string */
|
2019-01-31 18:50:41 +00:00
|
|
|
DEVLINK_ATTR_INFO_VERSION_FIXED, /* nested */
|
|
|
|
|
DEVLINK_ATTR_INFO_VERSION_RUNNING, /* nested */
|
|
|
|
|
DEVLINK_ATTR_INFO_VERSION_STORED, /* nested */
|
|
|
|
|
DEVLINK_ATTR_INFO_VERSION_NAME, /* string */
|
|
|
|
|
DEVLINK_ATTR_INFO_VERSION_VALUE, /* string */
|
2019-01-31 18:50:40 +00:00
|
|
|
|
2019-02-02 01:56:28 +00:00
|
|
|
DEVLINK_ATTR_SB_POOL_CELL_SIZE, /* u32 */
|
|
|
|
|
|
2019-02-07 09:36:32 +00:00
|
|
|
DEVLINK_ATTR_FMSG, /* nested */
|
|
|
|
|
DEVLINK_ATTR_FMSG_OBJ_NEST_START, /* flag */
|
|
|
|
|
DEVLINK_ATTR_FMSG_PAIR_NEST_START, /* flag */
|
|
|
|
|
DEVLINK_ATTR_FMSG_ARR_NEST_START, /* flag */
|
|
|
|
|
DEVLINK_ATTR_FMSG_NEST_END, /* flag */
|
|
|
|
|
DEVLINK_ATTR_FMSG_OBJ_NAME, /* string */
|
|
|
|
|
DEVLINK_ATTR_FMSG_OBJ_VALUE_TYPE, /* u8 */
|
|
|
|
|
DEVLINK_ATTR_FMSG_OBJ_VALUE_DATA, /* dynamic */
|
2019-02-07 09:36:35 +00:00
|
|
|
|
|
|
|
|
DEVLINK_ATTR_HEALTH_REPORTER, /* nested */
|
|
|
|
|
DEVLINK_ATTR_HEALTH_REPORTER_NAME, /* string */
|
|
|
|
|
DEVLINK_ATTR_HEALTH_REPORTER_STATE, /* u8 */
|
2019-02-21 12:12:01 +00:00
|
|
|
DEVLINK_ATTR_HEALTH_REPORTER_ERR_COUNT, /* u64 */
|
|
|
|
|
DEVLINK_ATTR_HEALTH_REPORTER_RECOVER_COUNT, /* u64 */
|
2019-02-07 09:36:35 +00:00
|
|
|
DEVLINK_ATTR_HEALTH_REPORTER_DUMP_TS, /* u64 */
|
|
|
|
|
DEVLINK_ATTR_HEALTH_REPORTER_GRACEFUL_PERIOD, /* u64 */
|
|
|
|
|
DEVLINK_ATTR_HEALTH_REPORTER_AUTO_RECOVER, /* u8 */
|
2019-02-14 21:40:44 +00:00
|
|
|
|
|
|
|
|
DEVLINK_ATTR_FLASH_UPDATE_FILE_NAME, /* string */
|
|
|
|
|
DEVLINK_ATTR_FLASH_UPDATE_COMPONENT, /* string */
|
2019-06-04 13:40:40 +00:00
|
|
|
DEVLINK_ATTR_FLASH_UPDATE_STATUS_MSG, /* string */
|
|
|
|
|
DEVLINK_ATTR_FLASH_UPDATE_STATUS_DONE, /* u64 */
|
|
|
|
|
DEVLINK_ATTR_FLASH_UPDATE_STATUS_TOTAL, /* u64 */
|
2019-02-14 21:40:44 +00:00
|
|
|
|
2019-07-09 04:17:37 +00:00
|
|
|
DEVLINK_ATTR_PORT_PCI_PF_NUMBER, /* u16 */
|
2019-07-09 04:17:38 +00:00
|
|
|
DEVLINK_ATTR_PORT_PCI_VF_NUMBER, /* u16 */
|
|
|
|
|
|
devlink: Add packet trap infrastructure
Add the basic packet trap infrastructure that allows device drivers to
register their supported packet traps and trap groups with devlink.
Each driver is expected to provide basic information about each
supported trap, such as name and ID, but also the supported metadata
types that will accompany each packet trapped via the trap. The
currently supported metadata type is just the input port, but more will
be added in the future. For example, output port and traffic class.
Trap groups allow users to set the action of all member traps. In
addition, users can retrieve per-group statistics in case per-trap
statistics are too narrow. In the future, the trap group object can be
extended with more attributes, such as policer settings which will limit
the amount of traffic generated by member traps towards the CPU.
Beside registering their packet traps with devlink, drivers are also
expected to report trapped packets to devlink along with relevant
metadata. devlink will maintain packets and bytes statistics for each
packet trap and will potentially report the trapped packet with its
metadata to user space via drop monitor netlink channel.
The interface towards the drivers is simple and allows devlink to set
the action of the trap. Currently, only two actions are supported:
'trap' and 'drop'. When set to 'trap', the device is expected to provide
the sole copy of the packet to the driver which will pass it to devlink.
When set to 'drop', the device is expected to drop the packet and not
send a copy to the driver. In the future, more actions can be added,
such as 'mirror'.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-17 13:28:17 +00:00
|
|
|
DEVLINK_ATTR_STATS, /* nested */
|
|
|
|
|
|
|
|
|
|
DEVLINK_ATTR_TRAP_NAME, /* string */
|
|
|
|
|
/* enum devlink_trap_action */
|
|
|
|
|
DEVLINK_ATTR_TRAP_ACTION, /* u8 */
|
|
|
|
|
/* enum devlink_trap_type */
|
|
|
|
|
DEVLINK_ATTR_TRAP_TYPE, /* u8 */
|
|
|
|
|
DEVLINK_ATTR_TRAP_GENERIC, /* flag */
|
|
|
|
|
DEVLINK_ATTR_TRAP_METADATA, /* nested */
|
|
|
|
|
DEVLINK_ATTR_TRAP_GROUP_NAME, /* string */
|
|
|
|
|
|
2019-09-12 08:49:46 +00:00
|
|
|
DEVLINK_ATTR_RELOAD_FAILED, /* u8 0 or 1 */
|
|
|
|
|
|
2019-11-10 12:11:56 +00:00
|
|
|
DEVLINK_ATTR_HEALTH_REPORTER_DUMP_TS_NS, /* u64 */
|
2019-11-17 02:47:31 +00:00
|
|
|
|
2019-10-03 09:49:39 +00:00
|
|
|
DEVLINK_ATTR_NETNS_FD, /* u32 */
|
|
|
|
|
DEVLINK_ATTR_NETNS_PID, /* u32 */
|
|
|
|
|
DEVLINK_ATTR_NETNS_ID, /* u32 */
|
2020-03-29 11:05:55 +00:00
|
|
|
|
|
|
|
|
DEVLINK_ATTR_HEALTH_REPORTER_AUTO_DUMP, /* u8 */
|
2020-03-30 19:38:18 +00:00
|
|
|
|
|
|
|
|
DEVLINK_ATTR_TRAP_POLICER_ID, /* u32 */
|
|
|
|
|
DEVLINK_ATTR_TRAP_POLICER_RATE, /* u64 */
|
|
|
|
|
DEVLINK_ATTR_TRAP_POLICER_BURST, /* u64 */
|
|
|
|
|
|
2020-06-19 03:32:48 +00:00
|
|
|
DEVLINK_ATTR_PORT_FUNCTION, /* nested */
|
|
|
|
|
|
2020-06-20 16:31:56 +00:00
|
|
|
DEVLINK_ATTR_INFO_BOARD_SERIAL_NUMBER, /* string */
|
|
|
|
|
|
2020-07-09 13:18:18 +00:00
|
|
|
DEVLINK_ATTR_PORT_LANES, /* u32 */
|
2020-07-09 13:18:20 +00:00
|
|
|
DEVLINK_ATTR_PORT_SPLITTABLE, /* u8 */
|
2020-07-09 13:18:18 +00:00
|
|
|
|
2020-09-09 04:50:36 +00:00
|
|
|
DEVLINK_ATTR_PORT_EXTERNAL, /* u8 */
|
devlink: Introduce controller number
A devlink port may be for a controller consist of PCI device.
A devlink instance holds ports of two types of controllers.
(1) controller discovered on same system where eswitch resides
This is the case where PCI PF/VF of a controller and devlink eswitch
instance both are located on a single system.
(2) controller located on external host system.
This is the case where a controller is located in one system and its
devlink eswitch ports are located in a different system.
When a devlink eswitch instance serves the devlink ports of both
controllers together, PCI PF/VF numbers may overlap.
Due to this a unique phys_port_name cannot be constructed.
For example in below such system controller-0 and controller-1, each has
PCI PF pf0 whose eswitch ports can be present in controller-0.
These results in phys_port_name as "pf0" for both.
Similar problem exists for VFs and upcoming Sub functions.
An example view of two controller systems:
---------------------------------------------------------
| |
| --------- --------- ------- ------- |
----------- | | vf(s) | | sf(s) | |vf(s)| |sf(s)| |
| server | | ------- ----/---- ---/----- ------- ---/--- ---/--- |
| pci rc |=== | pf0 |______/________/ | pf1 |___/_______/ |
| connect | | ------- ------- |
----------- | | controller_num=1 (no eswitch) |
------|--------------------------------------------------
(internal wire)
|
---------------------------------------------------------
| devlink eswitch ports and reps |
| ----------------------------------------------------- |
| |ctrl-0 | ctrl-0 | ctrl-0 | ctrl-0 | ctrl-0 |ctrl-0 | |
| |pf0 | pf0vfN | pf0sfN | pf1 | pf1vfN |pf1sfN | |
| ----------------------------------------------------- |
| |ctrl-1 | ctrl-1 | ctrl-1 | ctrl-1 | ctrl-1 |ctrl-1 | |
| |pf1 | pf1vfN | pf1sfN | pf1 | pf1vfN |pf0sfN | |
| ----------------------------------------------------- |
| |
| |
| --------- --------- ------- ------- |
| | vf(s) | | sf(s) | |vf(s)| |sf(s)| |
| ------- ----/---- ---/----- ------- ---/--- ---/--- |
| | pf0 |______/________/ | pf1 |___/_______/ |
| ------- ------- |
| |
| local controller_num=0 (eswitch) |
---------------------------------------------------------
An example devlink port for external controller with controller
number = 1 for a VF 1 of PF 0:
$ devlink port show pci/0000:06:00.0/2
pci/0000:06:00.0/2: type eth netdev ens2f0pf0vf1 flavour pcivf controller 1 pfnum 0 vfnum 1 external true splittable false
function:
hw_addr 00:00:00:00:00:00
$ devlink port show pci/0000:06:00.0/2 -jp
{
"port": {
"pci/0000:06:00.0/2": {
"type": "eth",
"netdev": "ens2f0pf0vf1",
"flavour": "pcivf",
"controller": 1,
"pfnum": 0,
"vfnum": 1,
"external": true,
"splittable": false,
"function": {
"hw_addr": "00:00:00:00:00:00"
}
}
}
}
Signed-off-by: Parav Pandit <parav@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-09 04:50:37 +00:00
|
|
|
DEVLINK_ATTR_PORT_CONTROLLER_NUMBER, /* u32 */
|
2020-09-18 01:13:23 +00:00
|
|
|
|
|
|
|
|
DEVLINK_ATTR_FLASH_UPDATE_STATUS_TIMEOUT, /* u64 */
|
devlink: introduce flash update overwrite mask
Sections of device flash may contain settings or device identifying
information. When performing a flash update, it is generally expected
that these settings and identifiers are not overwritten.
However, it may sometimes be useful to allow overwriting these fields
when performing a flash update. Some examples include, 1) customizing
the initial device config on first programming, such as overwriting
default device identifying information, or 2) reverting a device
configuration to known good state provided in the new firmware image, or
3) in case it is suspected that current firmware logic for managing the
preservation of fields during an update is broken.
Although some devices are able to completely separate these types of
settings and fields into separate components, this is not true for all
hardware.
To support controlling this behavior, a new
DEVLINK_ATTR_FLASH_UPDATE_OVERWRITE_MASK is defined. This is an
nla_bitfield32 which will define what subset of fields in a component
should be overwritten during an update.
If no bits are specified, or of the overwrite mask is not provided, then
an update should not overwrite anything, and should maintain the
settings and identifiers as they are in the previous image.
If the overwrite mask has the DEVLINK_FLASH_OVERWRITE_SETTINGS bit set,
then the device should be configured to overwrite any of the settings in
the requested component with settings found in the provided image.
Similarly, if the DEVLINK_FLASH_OVERWRITE_IDENTIFIERS bit is set, the
device should be configured to overwrite any device identifiers in the
requested component with the identifiers from the image.
Multiple overwrite modes may be combined to indicate that a combination
of the set of fields that should be overwritten.
Drivers which support the new overwrite mask must set the
DEVLINK_SUPPORT_FLASH_UPDATE_OVERWRITE_MASK in the
supported_flash_update_params field of their devlink_ops.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-25 20:46:07 +00:00
|
|
|
DEVLINK_ATTR_FLASH_UPDATE_OVERWRITE_MASK, /* bitfield32 */
|
2020-09-18 01:13:23 +00:00
|
|
|
|
2020-10-07 06:00:43 +00:00
|
|
|
DEVLINK_ATTR_RELOAD_ACTION, /* u8 */
|
|
|
|
|
DEVLINK_ATTR_RELOAD_ACTIONS_PERFORMED, /* bitfield32 */
|
2020-10-07 06:00:44 +00:00
|
|
|
DEVLINK_ATTR_RELOAD_LIMITS, /* bitfield32 */
|
2020-10-07 06:00:43 +00:00
|
|
|
|
2020-10-07 06:00:45 +00:00
|
|
|
DEVLINK_ATTR_DEV_STATS, /* nested */
|
|
|
|
|
DEVLINK_ATTR_RELOAD_STATS, /* nested */
|
|
|
|
|
DEVLINK_ATTR_RELOAD_STATS_ENTRY, /* nested */
|
|
|
|
|
DEVLINK_ATTR_RELOAD_STATS_LIMIT, /* u8 */
|
|
|
|
|
DEVLINK_ATTR_RELOAD_STATS_VALUE, /* u32 */
|
devlink: Add remote reload stats
Add remote reload stats to hold the history of actions performed due
devlink reload commands initiated by remote host. For example, in case
firmware activation with reset finished successfully but was initiated
by remote host.
The function devlink_remote_reload_actions_performed() is exported to
enable drivers update on remote reload actions performed as it was not
initiated by their own devlink instance.
Expose devlink remote reload stats to the user through devlink dev get
command.
Examples:
$ devlink dev show
pci/0000:82:00.0:
stats:
reload:
driver_reinit 2 fw_activate 1 fw_activate_no_reset 0
remote_reload:
driver_reinit 0 fw_activate 0 fw_activate_no_reset 0
pci/0000:82:00.1:
stats:
reload:
driver_reinit 1 fw_activate 0 fw_activate_no_reset 0
remote_reload:
driver_reinit 1 fw_activate 1 fw_activate_no_reset 0
$ devlink dev show -jp
{
"dev": {
"pci/0000:82:00.0": {
"stats": {
"reload": {
"driver_reinit": 2,
"fw_activate": 1,
"fw_activate_no_reset": 0
},
"remote_reload": {
"driver_reinit": 0,
"fw_activate": 0,
"fw_activate_no_reset": 0
}
}
},
"pci/0000:82:00.1": {
"stats": {
"reload": {
"driver_reinit": 1,
"fw_activate": 0,
"fw_activate_no_reset": 0
},
"remote_reload": {
"driver_reinit": 1,
"fw_activate": 1,
"fw_activate_no_reset": 0
}
}
}
}
}
Signed-off-by: Moshe Shemesh <moshe@mellanox.com>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-07 06:00:46 +00:00
|
|
|
DEVLINK_ATTR_REMOTE_RELOAD_STATS, /* nested */
|
2020-11-23 05:36:25 +00:00
|
|
|
DEVLINK_ATTR_RELOAD_ACTION_INFO, /* nested */
|
|
|
|
|
DEVLINK_ATTR_RELOAD_ACTION_STATS, /* nested */
|
2020-10-07 06:00:45 +00:00
|
|
|
|
devlink: Introduce PCI SF port flavour and port attribute
A PCI sub-function (SF) represents a portion of the device similar
to PCI VF.
In an eswitch, PCI SF may have port which is normally represented
using a representor netdevice.
To have better visibility of eswitch port, its association with SF,
and its representor netdevice, introduce a PCI SF port flavour.
When devlink port flavour is PCI SF, fill up PCI SF attributes of the
port.
Extend port name creation using PCI PF and SF number scheme on best
effort basis, so that vendor drivers can skip defining their own
scheme.
This is done as cApfNSfM, where A, N and M are controller, PCI PF and
PCI SF number respectively.
This is similar to existing naming for PCI PF and PCI VF ports.
An example view of a PCI SF port:
$ devlink port show pci/0000:06:00.0/32768
pci/0000:06:00.0/32768: type eth netdev ens2f0npf0sf88 flavour pcisf controller 0 pfnum 0 sfnum 88 external false splittable false
function:
hw_addr 00:00:00:00:88:88 state active opstate attached
$ devlink port show pci/0000:06:00.0/32768 -jp
{
"port": {
"pci/0000:06:00.0/32768": {
"type": "eth",
"netdev": "ens2f0npf0sf88",
"flavour": "pcisf",
"controller": 0,
"pfnum": 0,
"sfnum": 88,
"splittable": false,
"function": {
"hw_addr": "00:00:00:00:88:88",
"state": "active",
"opstate": "attached"
}
}
}
}
Signed-off-by: Parav Pandit <parav@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Reviewed-by: Vu Pham <vuhuong@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-12-12 06:12:13 +00:00
|
|
|
DEVLINK_ATTR_PORT_PCI_SF_NUMBER, /* u32 */
|
2021-06-02 12:17:19 +00:00
|
|
|
|
|
|
|
|
DEVLINK_ATTR_RATE_TYPE, /* u16 */
|
2021-06-02 12:17:22 +00:00
|
|
|
DEVLINK_ATTR_RATE_TX_SHARE, /* u64 */
|
|
|
|
|
DEVLINK_ATTR_RATE_TX_MAX, /* u64 */
|
2021-06-02 12:17:25 +00:00
|
|
|
DEVLINK_ATTR_RATE_NODE_NAME, /* string */
|
2021-06-02 12:17:28 +00:00
|
|
|
DEVLINK_ATTR_RATE_PARENT_NODE_NAME, /* string */
|
2021-06-02 12:17:25 +00:00
|
|
|
|
2021-09-30 21:21:04 +00:00
|
|
|
DEVLINK_ATTR_REGION_MAX_SNAPSHOTS, /* u32 */
|
|
|
|
|
|
2022-04-18 06:42:25 +00:00
|
|
|
DEVLINK_ATTR_LINECARD_INDEX, /* u32 */
|
2022-04-18 06:42:26 +00:00
|
|
|
DEVLINK_ATTR_LINECARD_STATE, /* u8 */
|
|
|
|
|
DEVLINK_ATTR_LINECARD_TYPE, /* string */
|
|
|
|
|
DEVLINK_ATTR_LINECARD_SUPPORTED_TYPES, /* nested */
|
2022-04-18 06:42:25 +00:00
|
|
|
|
2022-07-25 08:29:16 +00:00
|
|
|
DEVLINK_ATTR_NESTED_DEVLINK, /* nested */
|
|
|
|
|
|
2022-07-27 16:57:20 +00:00
|
|
|
DEVLINK_ATTR_SELFTESTS, /* nested */
|
|
|
|
|
|
2022-11-15 10:48:15 +00:00
|
|
|
DEVLINK_ATTR_RATE_TX_PRIORITY, /* u32 */
|
2022-11-15 10:48:16 +00:00
|
|
|
DEVLINK_ATTR_RATE_TX_WEIGHT, /* u32 */
|
|
|
|
|
|
2022-11-28 20:36:44 +00:00
|
|
|
DEVLINK_ATTR_REGION_DIRECT, /* flag */
|
|
|
|
|
|
2024-03-10 14:55:03 +00:00
|
|
|
/* Add new attributes above here, update the spec in
|
|
|
|
|
* Documentation/netlink/specs/devlink.yaml and re-generate
|
|
|
|
|
* net/devlink/netlink_gen.c.
|
|
|
|
|
*/
|
2016-02-26 16:32:23 +00:00
|
|
|
|
|
|
|
|
__DEVLINK_ATTR_MAX,
|
|
|
|
|
DEVLINK_ATTR_MAX = __DEVLINK_ATTR_MAX - 1
|
|
|
|
|
};
|
|
|
|
|
|
2017-03-28 15:24:10 +00:00
|
|
|
/* Mapping between internal resource described by the field and system
|
|
|
|
|
* structure
|
|
|
|
|
*/
|
|
|
|
|
enum devlink_dpipe_field_mapping_type {
|
|
|
|
|
DEVLINK_DPIPE_FIELD_MAPPING_TYPE_NONE,
|
|
|
|
|
DEVLINK_DPIPE_FIELD_MAPPING_TYPE_IFINDEX,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* Match type - specify the type of the match */
|
|
|
|
|
enum devlink_dpipe_match_type {
|
|
|
|
|
DEVLINK_DPIPE_MATCH_TYPE_FIELD_EXACT,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* Action type - specify the action type */
|
|
|
|
|
enum devlink_dpipe_action_type {
|
|
|
|
|
DEVLINK_DPIPE_ACTION_TYPE_FIELD_MODIFY,
|
|
|
|
|
};
|
|
|
|
|
|
2017-08-24 06:39:59 +00:00
|
|
|
enum devlink_dpipe_field_ethernet_id {
|
|
|
|
|
DEVLINK_DPIPE_FIELD_ETHERNET_DST_MAC,
|
|
|
|
|
};
|
|
|
|
|
|
2017-08-24 06:40:00 +00:00
|
|
|
enum devlink_dpipe_field_ipv4_id {
|
|
|
|
|
DEVLINK_DPIPE_FIELD_IPV4_DST_IP,
|
|
|
|
|
};
|
|
|
|
|
|
2017-08-31 15:59:12 +00:00
|
|
|
enum devlink_dpipe_field_ipv6_id {
|
|
|
|
|
DEVLINK_DPIPE_FIELD_IPV6_DST_IP,
|
|
|
|
|
};
|
|
|
|
|
|
2017-08-24 06:39:59 +00:00
|
|
|
enum devlink_dpipe_header_id {
|
|
|
|
|
DEVLINK_DPIPE_HEADER_ETHERNET,
|
2017-08-24 06:40:00 +00:00
|
|
|
DEVLINK_DPIPE_HEADER_IPV4,
|
2017-08-31 15:59:12 +00:00
|
|
|
DEVLINK_DPIPE_HEADER_IPV6,
|
2017-08-24 06:39:59 +00:00
|
|
|
};
|
|
|
|
|
|
2018-01-15 07:59:03 +00:00
|
|
|
enum devlink_resource_unit {
|
|
|
|
|
DEVLINK_RESOURCE_UNIT_ENTRY,
|
|
|
|
|
};
|
|
|
|
|
|
2022-12-06 18:51:15 +00:00
|
|
|
enum devlink_port_fn_attr_cap {
|
|
|
|
|
DEVLINK_PORT_FN_ATTR_CAP_ROCE_BIT,
|
2022-12-06 18:51:18 +00:00
|
|
|
DEVLINK_PORT_FN_ATTR_CAP_MIGRATABLE_BIT,
|
2023-08-25 06:28:29 +00:00
|
|
|
DEVLINK_PORT_FN_ATTR_CAP_IPSEC_CRYPTO_BIT,
|
2023-08-25 06:28:30 +00:00
|
|
|
DEVLINK_PORT_FN_ATTR_CAP_IPSEC_PACKET_BIT,
|
2022-12-06 18:51:15 +00:00
|
|
|
|
|
|
|
|
/* Add new caps above */
|
|
|
|
|
__DEVLINK_PORT_FN_ATTR_CAPS_MAX,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#define DEVLINK_PORT_FN_CAP_ROCE _BITUL(DEVLINK_PORT_FN_ATTR_CAP_ROCE_BIT)
|
2022-12-06 18:51:18 +00:00
|
|
|
#define DEVLINK_PORT_FN_CAP_MIGRATABLE \
|
|
|
|
|
_BITUL(DEVLINK_PORT_FN_ATTR_CAP_MIGRATABLE_BIT)
|
2023-08-25 06:28:29 +00:00
|
|
|
#define DEVLINK_PORT_FN_CAP_IPSEC_CRYPTO _BITUL(DEVLINK_PORT_FN_ATTR_CAP_IPSEC_CRYPTO_BIT)
|
2023-08-25 06:28:30 +00:00
|
|
|
#define DEVLINK_PORT_FN_CAP_IPSEC_PACKET _BITUL(DEVLINK_PORT_FN_ATTR_CAP_IPSEC_PACKET_BIT)
|
2022-12-06 18:51:15 +00:00
|
|
|
|
2020-06-19 03:32:48 +00:00
|
|
|
enum devlink_port_function_attr {
|
|
|
|
|
DEVLINK_PORT_FUNCTION_ATTR_UNSPEC,
|
|
|
|
|
DEVLINK_PORT_FUNCTION_ATTR_HW_ADDR, /* binary */
|
devlink: Support get and set state of port function
devlink port function can be in active or inactive state.
Allow users to get and set port function's state.
When the port function it activated, its operational state may change
after a while when the device is created and driver binds to it.
Similarly on deactivation flow.
To clearly describe the state of the port function and its device's
operational state in the host system, define state and opstate
attributes.
Example of a PCI SF port which supports a port function:
$ devlink dev eswitch set pci/0000:06:00.0 mode switchdev
$ devlink port show
pci/0000:06:00.0/65535: type eth netdev ens2f0np0 flavour physical port 0 splittable false
$ devlink port add pci/0000:06:00.0 flavour pcisf pfnum 0 sfnum 88
pci/0000:08:00.0/32768: type eth netdev eth6 flavour pcisf controller 0 pfnum 0 sfnum 88 external false splittable false
function:
hw_addr 00:00:00:00:00:00 state inactive opstate detached
$ devlink port show pci/0000:06:00.0/32768
pci/0000:06:00.0/32768: type eth netdev ens2f0npf0sf88 flavour pcisf controller 0 pfnum 0 sfnum 88 external false splittable false
function:
hw_addr 00:00:00:00:88:88 state inactive opstate detached
$ devlink port function set pci/0000:06:00.0/32768 hw_addr 00:00:00:00:88:88 state active
$ devlink port show pci/0000:06:00.0/32768 -jp
{
"port": {
"pci/0000:06:00.0/32768": {
"type": "eth",
"netdev": "ens2f0npf0sf88",
"flavour": "pcisf",
"controller": 0,
"pfnum": 0,
"sfnum": 88,
"external": false,
"splittable": false,
"function": {
"hw_addr": "00:00:00:00:88:88",
"state": "active",
"opstate": "attached"
}
}
}
}
Signed-off-by: Parav Pandit <parav@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Reviewed-by: Vu Pham <vuhuong@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-12-12 06:12:15 +00:00
|
|
|
DEVLINK_PORT_FN_ATTR_STATE, /* u8 */
|
|
|
|
|
DEVLINK_PORT_FN_ATTR_OPSTATE, /* u8 */
|
2022-12-06 18:51:15 +00:00
|
|
|
DEVLINK_PORT_FN_ATTR_CAPS, /* bitfield32 */
|
2023-09-13 07:12:39 +00:00
|
|
|
DEVLINK_PORT_FN_ATTR_DEVLINK, /* nested */
|
2020-06-19 03:32:48 +00:00
|
|
|
|
|
|
|
|
__DEVLINK_PORT_FUNCTION_ATTR_MAX,
|
|
|
|
|
DEVLINK_PORT_FUNCTION_ATTR_MAX = __DEVLINK_PORT_FUNCTION_ATTR_MAX - 1
|
|
|
|
|
};
|
|
|
|
|
|
devlink: Support get and set state of port function
devlink port function can be in active or inactive state.
Allow users to get and set port function's state.
When the port function it activated, its operational state may change
after a while when the device is created and driver binds to it.
Similarly on deactivation flow.
To clearly describe the state of the port function and its device's
operational state in the host system, define state and opstate
attributes.
Example of a PCI SF port which supports a port function:
$ devlink dev eswitch set pci/0000:06:00.0 mode switchdev
$ devlink port show
pci/0000:06:00.0/65535: type eth netdev ens2f0np0 flavour physical port 0 splittable false
$ devlink port add pci/0000:06:00.0 flavour pcisf pfnum 0 sfnum 88
pci/0000:08:00.0/32768: type eth netdev eth6 flavour pcisf controller 0 pfnum 0 sfnum 88 external false splittable false
function:
hw_addr 00:00:00:00:00:00 state inactive opstate detached
$ devlink port show pci/0000:06:00.0/32768
pci/0000:06:00.0/32768: type eth netdev ens2f0npf0sf88 flavour pcisf controller 0 pfnum 0 sfnum 88 external false splittable false
function:
hw_addr 00:00:00:00:88:88 state inactive opstate detached
$ devlink port function set pci/0000:06:00.0/32768 hw_addr 00:00:00:00:88:88 state active
$ devlink port show pci/0000:06:00.0/32768 -jp
{
"port": {
"pci/0000:06:00.0/32768": {
"type": "eth",
"netdev": "ens2f0npf0sf88",
"flavour": "pcisf",
"controller": 0,
"pfnum": 0,
"sfnum": 88,
"external": false,
"splittable": false,
"function": {
"hw_addr": "00:00:00:00:88:88",
"state": "active",
"opstate": "attached"
}
}
}
}
Signed-off-by: Parav Pandit <parav@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Reviewed-by: Vu Pham <vuhuong@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-12-12 06:12:15 +00:00
|
|
|
enum devlink_port_fn_state {
|
|
|
|
|
DEVLINK_PORT_FN_STATE_INACTIVE,
|
|
|
|
|
DEVLINK_PORT_FN_STATE_ACTIVE,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* enum devlink_port_fn_opstate - indicates operational state of the function
|
|
|
|
|
* @DEVLINK_PORT_FN_OPSTATE_ATTACHED: Driver is attached to the function.
|
|
|
|
|
* For graceful tear down of the function, after inactivation of the
|
|
|
|
|
* function, user should wait for operational state to turn DETACHED.
|
|
|
|
|
* @DEVLINK_PORT_FN_OPSTATE_DETACHED: Driver is detached from the function.
|
|
|
|
|
* It is safe to delete the port.
|
|
|
|
|
*/
|
|
|
|
|
enum devlink_port_fn_opstate {
|
|
|
|
|
DEVLINK_PORT_FN_OPSTATE_DETACHED,
|
|
|
|
|
DEVLINK_PORT_FN_OPSTATE_ATTACHED,
|
|
|
|
|
};
|
|
|
|
|
|
2016-02-26 16:32:23 +00:00
|
|
|
#endif /* _UAPI_LINUX_DEVLINK_H_ */
|