2019-05-27 09:55:01 +03:00
/* SPDX-License-Identifier: GPL-2.0-or-later */
2016-02-26 19:32:23 +03:00
/*
* include / net / devlink . h - Network physical device Netlink interface
* Copyright ( c ) 2016 Mellanox Technologies . All rights reserved .
* Copyright ( c ) 2016 Jiri Pirko < jiri @ mellanox . com >
*/
# ifndef _NET_DEVLINK_H_
# define _NET_DEVLINK_H_
# include <linux/device.h>
# include <linux/slab.h>
# include <linux/gfp.h>
# include <linux/list.h>
# include <linux/netdevice.h>
2019-03-24 13:14:37 +03:00
# include <linux/spinlock.h>
2019-05-23 11:43:35 +03:00
# include <linux/workqueue.h>
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 16:28:17 +03:00
# include <linux/refcount.h>
2016-02-26 19:32:23 +03:00
# include <net/net_namespace.h>
2020-02-25 13:45:21 +03:00
# include <net/flow_offload.h>
2016-02-26 19:32:23 +03:00
# include <uapi/linux/devlink.h>
2020-03-26 21:37:15 +03:00
# include <linux/xarray.h>
2020-11-18 22:06:35 +03:00
# include <linux/firmware.h>
2016-02-26 19:32:23 +03:00
2021-10-12 16:15:21 +03:00
struct devlink ;
2022-04-18 09:42:25 +03:00
struct devlink_linecard ;
2016-02-26 19:32:23 +03:00
2019-07-09 07:17:35 +03:00
struct devlink_port_phys_attrs {
u32 port_number ; /* Same value as "split group".
* A physical port which is visible to the user
* for a given port flavour .
*/
2020-07-09 16:18:16 +03:00
u32 split_subport_number ; /* If the port is split, this is the number of subport. */
2019-07-09 07:17:35 +03:00
} ;
2020-09-09 07:50:35 +03:00
/**
* struct devlink_port_pci_pf_attrs - devlink port ' s PCI PF attributes
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 07:50:37 +03:00
* @ controller : Associated controller number
2020-09-09 07:50:35 +03:00
* @ pf : Associated PCI PF number for this port .
2020-09-09 07:50:36 +03:00
* @ external : when set , indicates if a port is for an external controller
2020-09-09 07:50:35 +03:00
*/
2019-07-09 07:17:37 +03:00
struct devlink_port_pci_pf_attrs {
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 07:50:37 +03:00
u32 controller ;
2020-09-09 07:50:35 +03:00
u16 pf ;
2020-09-09 07:50:36 +03:00
u8 external : 1 ;
2019-07-09 07:17:37 +03:00
} ;
2020-09-09 07:50:35 +03:00
/**
* struct devlink_port_pci_vf_attrs - devlink port ' s PCI VF attributes
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 07:50:37 +03:00
* @ controller : Associated controller number
2020-09-09 07:50:35 +03:00
* @ pf : Associated PCI PF number for this port .
* @ vf : Associated PCI VF for of the PCI PF for this port .
2020-09-09 07:50:36 +03:00
* @ external : when set , indicates if a port is for an external controller
2020-09-09 07:50:35 +03:00
*/
2019-07-09 07:17:38 +03:00
struct devlink_port_pci_vf_attrs {
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 07:50:37 +03:00
u32 controller ;
2020-09-09 07:50:35 +03:00
u16 pf ;
u16 vf ;
2020-09-09 07:50:36 +03:00
u8 external : 1 ;
2019-07-09 07:17:38 +03: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 09:12:13 +03:00
/**
* struct devlink_port_pci_sf_attrs - devlink port ' s PCI SF attributes
* @ controller : Associated controller number
* @ sf : Associated PCI SF for of the PCI PF for this port .
* @ pf : Associated PCI PF number for this port .
2021-03-10 16:35:03 +03:00
* @ external : when set , indicates if a port is for an external controller
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 09:12:13 +03:00
*/
struct devlink_port_pci_sf_attrs {
u32 controller ;
u32 sf ;
u16 pf ;
2021-03-10 16:35:03 +03:00
u8 external : 1 ;
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 09:12:13 +03:00
} ;
2020-07-09 16:18:16 +03:00
/**
* struct devlink_port_attrs - devlink port object
* @ flavour : flavour of the port
* @ split : indicates if this is split port
2020-07-09 16:18:20 +03:00
* @ splittable : indicates if the port can be split .
2020-07-09 16:18:18 +03:00
* @ lanes : maximum number of lanes the port supports . 0 value is not passed to netlink .
2020-07-09 16:18:16 +03:00
* @ switch_id : if the port is part of switch , this is buffer with ID , otherwise this is NULL
2020-09-09 07:50:34 +03:00
* @ phys : physical port attributes
* @ pci_pf : PCI PF port attributes
* @ pci_vf : PCI VF port attributes
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 09:12:13 +03:00
* @ pci_sf : PCI SF port attributes
2020-07-09 16:18:16 +03:00
*/
2018-05-18 10:29:00 +03:00
struct devlink_port_attrs {
2020-07-09 16:18:20 +03:00
u8 split : 1 ,
splittable : 1 ;
2020-07-09 16:18:18 +03:00
u32 lanes ;
2018-05-18 10:29:01 +03:00
enum devlink_port_flavour flavour ;
2019-04-03 15:24:16 +03:00
struct netdev_phys_item_id switch_id ;
2019-07-09 07:17:35 +03:00
union {
struct devlink_port_phys_attrs phys ;
2019-07-09 07:17:37 +03:00
struct devlink_port_pci_pf_attrs pci_pf ;
2019-07-09 07:17:38 +03:00
struct devlink_port_pci_vf_attrs pci_vf ;
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 09:12:13 +03:00
struct devlink_port_pci_sf_attrs pci_sf ;
2019-07-09 07:17:35 +03:00
} ;
2018-05-18 10:29:00 +03:00
} ;
2021-06-02 15:17:19 +03:00
struct devlink_rate {
struct list_head list ;
enum devlink_rate_type type ;
struct devlink * devlink ;
void * priv ;
2021-06-02 15:17:22 +03:00
u64 tx_share ;
u64 tx_max ;
2021-06-02 15:17:19 +03:00
2021-06-02 15:17:28 +03:00
struct devlink_rate * parent ;
2021-06-02 15:17:25 +03:00
union {
struct devlink_port * devlink_port ;
2021-06-02 15:17:28 +03:00
struct {
char * name ;
refcount_t refcnt ;
} ;
2021-06-02 15:17:25 +03:00
} ;
2021-06-02 15:17:19 +03:00
} ;
2016-02-26 19:32:23 +03:00
struct devlink_port {
struct list_head list ;
2019-01-28 15:30:20 +03:00
struct list_head param_list ;
2020-10-04 19:12:54 +03:00
struct list_head region_list ;
2016-02-26 19:32:23 +03:00
struct devlink * devlink ;
2019-08-30 13:39:44 +03:00
unsigned int index ;
2019-03-24 13:14:37 +03:00
spinlock_t type_lock ; /* Protects type and type_dev
* pointer consistency .
*/
2016-02-26 19:32:23 +03:00
enum devlink_port_type type ;
enum devlink_port_type desired_type ;
void * type_dev ;
2018-05-18 10:29:00 +03:00
struct devlink_port_attrs attrs ;
2020-07-09 16:18:15 +03:00
u8 attrs_set : 1 ,
switch_port : 1 ;
2019-05-23 11:43:35 +03:00
struct delayed_work type_warn_dw ;
2020-07-10 15:25:10 +03:00
struct list_head reporter_list ;
struct mutex reporters_lock ; /* Protects reporter_list */
2021-06-02 15:17:19 +03:00
struct devlink_rate * devlink_rate ;
2022-04-18 09:42:28 +03:00
struct devlink_linecard * linecard ;
2016-02-26 19:32:23 +03:00
} ;
2020-12-12 09:12:14 +03:00
struct devlink_port_new_attrs {
enum devlink_port_flavour flavour ;
unsigned int port_index ;
u32 controller ;
u32 sfnum ;
u16 pfnum ;
u8 port_index_valid : 1 ,
controller_valid : 1 ,
sfnum_valid : 1 ;
} ;
2022-04-18 09:42:26 +03:00
/**
* struct devlink_linecard_ops - Linecard operations
* @ provision : callback to provision the linecard slot with certain
* type of linecard . As a result of this operation ,
* driver is expected to eventually ( could be after
* the function call returns ) call one of :
* devlink_linecard_provision_set ( )
* devlink_linecard_provision_fail ( )
* @ unprovision : callback to unprovision the linecard slot . As a result
* of this operation , driver is expected to eventually
* ( could be after the function call returns ) call
* devlink_linecard_provision_clear ( )
* devlink_linecard_provision_fail ( )
* @ same_provision : callback to ask the driver if linecard is already
* provisioned in the same way user asks this linecard to be
* provisioned .
* @ types_count : callback to get number of supported types
* @ types_get : callback to get next type in list
*/
struct devlink_linecard_ops {
int ( * provision ) ( struct devlink_linecard * linecard , void * priv ,
const char * type , const void * type_priv ,
struct netlink_ext_ack * extack ) ;
int ( * unprovision ) ( struct devlink_linecard * linecard , void * priv ,
struct netlink_ext_ack * extack ) ;
bool ( * same_provision ) ( struct devlink_linecard * linecard , void * priv ,
const char * type , const void * type_priv ) ;
unsigned int ( * types_count ) ( struct devlink_linecard * linecard ,
void * priv ) ;
void ( * types_get ) ( struct devlink_linecard * linecard ,
void * priv , unsigned int index , const char * * type ,
const void * * type_priv ) ;
} ;
2016-04-14 19:19:13 +03:00
struct devlink_sb_pool_info {
enum devlink_sb_pool_type pool_type ;
u32 size ;
enum devlink_sb_threshold_type threshold_type ;
2019-02-02 04:56:28 +03:00
u32 cell_size ;
2016-04-14 19:19:13 +03:00
} ;
2017-03-28 18:24:10 +03:00
/**
* struct devlink_dpipe_field - dpipe field object
* @ name : field name
* @ id : index inside the headers field array
* @ bitwidth : bitwidth
* @ mapping_type : mapping type
*/
struct devlink_dpipe_field {
const char * name ;
unsigned int id ;
unsigned int bitwidth ;
enum devlink_dpipe_field_mapping_type mapping_type ;
} ;
/**
* struct devlink_dpipe_header - dpipe header object
* @ name : header name
* @ id : index , global / local detrmined by global bit
* @ fields : fields
* @ fields_count : number of fields
* @ global : indicates if header is shared like most protocol header
* or driver specific
*/
struct devlink_dpipe_header {
const char * name ;
unsigned int id ;
struct devlink_dpipe_field * fields ;
unsigned int fields_count ;
bool global ;
} ;
/**
* struct devlink_dpipe_match - represents match operation
* @ type : type of match
* @ header_index : header index ( packets can have several headers of same
* type like in case of tunnels )
* @ header : header
* @ fieled_id : field index
*/
struct devlink_dpipe_match {
enum devlink_dpipe_match_type type ;
unsigned int header_index ;
struct devlink_dpipe_header * header ;
unsigned int field_id ;
} ;
/**
* struct devlink_dpipe_action - represents action operation
* @ type : type of action
* @ header_index : header index ( packets can have several headers of same
* type like in case of tunnels )
* @ header : header
* @ fieled_id : field index
*/
struct devlink_dpipe_action {
enum devlink_dpipe_action_type type ;
unsigned int header_index ;
struct devlink_dpipe_header * header ;
unsigned int field_id ;
} ;
/**
* struct devlink_dpipe_value - represents value of match / action
* @ action : action
* @ match : match
* @ mapping_value : in case the field has some mapping this value
* specified the mapping value
* @ mapping_valid : specify if mapping value is valid
* @ value_size : value size
* @ value : value
* @ mask : bit mask
*/
struct devlink_dpipe_value {
union {
struct devlink_dpipe_action * action ;
struct devlink_dpipe_match * match ;
} ;
unsigned int mapping_value ;
bool mapping_valid ;
unsigned int value_size ;
void * value ;
void * mask ;
} ;
/**
* struct devlink_dpipe_entry - table entry object
* @ index : index of the entry in the table
* @ match_values : match values
* @ matche_values_count : count of matches tuples
* @ action_values : actions values
* @ action_values_count : count of actions values
* @ counter : value of counter
* @ counter_valid : Specify if value is valid from hardware
*/
struct devlink_dpipe_entry {
u64 index ;
struct devlink_dpipe_value * match_values ;
unsigned int match_values_count ;
struct devlink_dpipe_value * action_values ;
unsigned int action_values_count ;
u64 counter ;
bool counter_valid ;
} ;
/**
* struct devlink_dpipe_dump_ctx - context provided to driver in order
* to dump
* @ info : info
* @ cmd : devlink command
* @ skb : skb
* @ nest : top attribute
* @ hdr : hdr
*/
struct devlink_dpipe_dump_ctx {
struct genl_info * info ;
enum devlink_command cmd ;
struct sk_buff * skb ;
struct nlattr * nest ;
void * hdr ;
} ;
struct devlink_dpipe_table_ops ;
/**
* struct devlink_dpipe_table - table object
* @ priv : private
* @ name : table name
* @ counters_enabled : indicates if counters are active
* @ counter_control_extern : indicates if counter control is in dpipe or
* external tool
2018-01-15 10:59:05 +03:00
* @ resource_valid : Indicate that the resource id is valid
* @ resource_id : relative resource this table is related to
* @ resource_units : number of resource ' s unit consumed per table ' s entry
2017-03-28 18:24:10 +03:00
* @ table_ops : table operations
* @ rcu : rcu
*/
struct devlink_dpipe_table {
void * priv ;
struct list_head list ;
const char * name ;
bool counters_enabled ;
bool counter_control_extern ;
2018-01-15 10:59:05 +03:00
bool resource_valid ;
u64 resource_id ;
u64 resource_units ;
2017-03-28 18:24:10 +03:00
struct devlink_dpipe_table_ops * table_ops ;
struct rcu_head rcu ;
} ;
/**
* struct devlink_dpipe_table_ops - dpipe_table ops
* @ actions_dump - dumps all tables actions
* @ matches_dump - dumps all tables matches
* @ entries_dump - dumps all active entries in the table
* @ counters_set_update - when changing the counter status hardware sync
* maybe needed to allocate / free counter related
* resources
2017-08-24 09:40:02 +03:00
* @ size_get - get size
2017-03-28 18:24:10 +03:00
*/
struct devlink_dpipe_table_ops {
int ( * actions_dump ) ( void * priv , struct sk_buff * skb ) ;
int ( * matches_dump ) ( void * priv , struct sk_buff * skb ) ;
int ( * entries_dump ) ( void * priv , bool counters_enabled ,
struct devlink_dpipe_dump_ctx * dump_ctx ) ;
int ( * counters_set_update ) ( void * priv , bool enable ) ;
2017-08-24 09:40:02 +03:00
u64 ( * size_get ) ( void * priv ) ;
2017-03-28 18:24:10 +03:00
} ;
/**
* struct devlink_dpipe_headers - dpipe headers
* @ headers - header array can be shared ( global bit ) or driver specific
* @ headers_count - count of headers
*/
struct devlink_dpipe_headers {
struct devlink_dpipe_header * * headers ;
unsigned int headers_count ;
} ;
2018-01-15 10:59:03 +03:00
/**
* struct devlink_resource_size_params - resource ' s size parameters
* @ size_min : minimum size which can be set
* @ size_max : maximum size which can be set
* @ size_granularity : size granularity
* @ size_unit : resource ' s basic unit
*/
struct devlink_resource_size_params {
u64 size_min ;
u64 size_max ;
u64 size_granularity ;
enum devlink_resource_unit unit ;
} ;
2018-02-28 15:12:09 +03:00
static inline void
devlink_resource_size_params_init ( struct devlink_resource_size_params * size_params ,
u64 size_min , u64 size_max ,
u64 size_granularity ,
enum devlink_resource_unit unit )
{
size_params - > size_min = size_min ;
size_params - > size_max = size_max ;
size_params - > size_granularity = size_granularity ;
size_params - > unit = unit ;
}
2018-04-05 23:13:21 +03:00
typedef u64 devlink_resource_occ_get_t ( void * priv ) ;
2018-01-15 10:59:03 +03:00
# define DEVLINK_RESOURCE_ID_PARENT_TOP 0
2021-01-21 16:10:23 +03:00
# define DEVLINK_RESOURCE_GENERIC_NAME_PORTS "physical_ports"
2018-10-10 16:09:27 +03:00
# define __DEVLINK_PARAM_MAX_STRING_VALUE 32
2018-07-04 14:30:28 +03:00
enum devlink_param_type {
DEVLINK_PARAM_TYPE_U8 ,
DEVLINK_PARAM_TYPE_U16 ,
DEVLINK_PARAM_TYPE_U32 ,
DEVLINK_PARAM_TYPE_STRING ,
DEVLINK_PARAM_TYPE_BOOL ,
} ;
union devlink_param_value {
u8 vu8 ;
u16 vu16 ;
u32 vu32 ;
2018-10-10 16:09:27 +03:00
char vstr [ __DEVLINK_PARAM_MAX_STRING_VALUE ] ;
2018-07-04 14:30:28 +03:00
bool vbool ;
} ;
struct devlink_param_gset_ctx {
union devlink_param_value val ;
enum devlink_param_cmode cmode ;
} ;
2020-09-18 04:13:24 +03:00
/**
* struct devlink_flash_notify - devlink dev flash notify data
* @ status_msg : current status string
* @ component : firmware component being updated
* @ done : amount of work completed of total amount
* @ total : amount of work expected to be done
* @ timeout : expected max timeout in seconds
*
* These are values to be given to userland to be displayed in order
* to show current activity in a firmware update process .
*/
struct devlink_flash_notify {
const char * status_msg ;
const char * component ;
unsigned long done ;
unsigned long total ;
unsigned long timeout ;
} ;
2018-07-04 14:30:28 +03:00
/**
* struct devlink_param - devlink configuration parameter data
* @ name : name of the parameter
* @ generic : indicates if the parameter is generic or driver specific
* @ type : parameter type
* @ supported_cmodes : bitmap of supported configuration modes
* @ get : get parameter value , used for runtime and permanent
* configuration modes
* @ set : set parameter value , used for runtime and permanent
* configuration modes
2018-07-04 14:30:30 +03:00
* @ validate : validate input value is applicable ( within value range , etc . )
2018-07-04 14:30:28 +03:00
*
* This struct should be used by the driver to fill the data for
* a parameter it registers .
*/
struct devlink_param {
u32 id ;
const char * name ;
bool generic ;
enum devlink_param_type type ;
unsigned long supported_cmodes ;
int ( * get ) ( struct devlink * devlink , u32 id ,
struct devlink_param_gset_ctx * ctx ) ;
int ( * set ) ( struct devlink * devlink , u32 id ,
struct devlink_param_gset_ctx * ctx ) ;
2018-07-04 14:30:30 +03:00
int ( * validate ) ( struct devlink * devlink , u32 id ,
union devlink_param_value val ,
struct netlink_ext_ack * extack ) ;
2018-07-04 14:30:28 +03:00
} ;
struct devlink_param_item {
struct list_head list ;
const struct devlink_param * param ;
union devlink_param_value driverinit_value ;
bool driverinit_value_valid ;
} ;
enum devlink_param_generic_id {
2018-07-04 14:30:33 +03:00
DEVLINK_PARAM_GENERIC_ID_INT_ERR_RESET ,
DEVLINK_PARAM_GENERIC_ID_MAX_MACS ,
2018-07-04 14:30:36 +03:00
DEVLINK_PARAM_GENERIC_ID_ENABLE_SRIOV ,
2018-07-12 15:13:17 +03:00
DEVLINK_PARAM_GENERIC_ID_REGION_SNAPSHOT ,
2018-10-04 08:43:44 +03:00
DEVLINK_PARAM_GENERIC_ID_IGNORE_ARI ,
2018-10-04 08:43:45 +03:00
DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MAX ,
2018-10-04 08:43:46 +03:00
DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MIN ,
2018-12-03 10:58:59 +03:00
DEVLINK_PARAM_GENERIC_ID_FW_LOAD_POLICY ,
2019-09-09 02:54:18 +03:00
DEVLINK_PARAM_GENERIC_ID_RESET_DEV_ON_DRV_PROBE ,
2019-11-09 02:45:20 +03:00
DEVLINK_PARAM_GENERIC_ID_ENABLE_ROCE ,
2020-10-07 09:00:53 +03:00
DEVLINK_PARAM_GENERIC_ID_ENABLE_REMOTE_DEV_RESET ,
2021-08-10 16:24:15 +03:00
DEVLINK_PARAM_GENERIC_ID_ENABLE_ETH ,
2021-08-10 16:24:16 +03:00
DEVLINK_PARAM_GENERIC_ID_ENABLE_RDMA ,
2021-08-10 16:24:17 +03:00
DEVLINK_PARAM_GENERIC_ID_ENABLE_VNET ,
2021-10-19 02:16:01 +03:00
DEVLINK_PARAM_GENERIC_ID_ENABLE_IWARP ,
2021-12-09 13:09:24 +03:00
DEVLINK_PARAM_GENERIC_ID_IO_EQ_SIZE ,
2021-12-09 13:09:26 +03:00
DEVLINK_PARAM_GENERIC_ID_EVENT_EQ_SIZE ,
2018-07-04 14:30:28 +03:00
/* add new param generic ids above here*/
__DEVLINK_PARAM_GENERIC_ID_MAX ,
DEVLINK_PARAM_GENERIC_ID_MAX = __DEVLINK_PARAM_GENERIC_ID_MAX - 1 ,
} ;
2018-07-04 14:30:33 +03:00
# define DEVLINK_PARAM_GENERIC_INT_ERR_RESET_NAME "internal_error_reset"
# define DEVLINK_PARAM_GENERIC_INT_ERR_RESET_TYPE DEVLINK_PARAM_TYPE_BOOL
# define DEVLINK_PARAM_GENERIC_MAX_MACS_NAME "max_macs"
# define DEVLINK_PARAM_GENERIC_MAX_MACS_TYPE DEVLINK_PARAM_TYPE_U32
2018-07-04 14:30:36 +03:00
# define DEVLINK_PARAM_GENERIC_ENABLE_SRIOV_NAME "enable_sriov"
# define DEVLINK_PARAM_GENERIC_ENABLE_SRIOV_TYPE DEVLINK_PARAM_TYPE_BOOL
2018-07-12 15:13:17 +03:00
# define DEVLINK_PARAM_GENERIC_REGION_SNAPSHOT_NAME "region_snapshot_enable"
# define DEVLINK_PARAM_GENERIC_REGION_SNAPSHOT_TYPE DEVLINK_PARAM_TYPE_BOOL
2018-10-04 08:43:44 +03:00
# define DEVLINK_PARAM_GENERIC_IGNORE_ARI_NAME "ignore_ari"
# define DEVLINK_PARAM_GENERIC_IGNORE_ARI_TYPE DEVLINK_PARAM_TYPE_BOOL
2018-10-04 08:43:45 +03:00
# define DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MAX_NAME "msix_vec_per_pf_max"
# define DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MAX_TYPE DEVLINK_PARAM_TYPE_U32
2018-10-04 08:43:46 +03:00
# define DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MIN_NAME "msix_vec_per_pf_min"
# define DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MIN_TYPE DEVLINK_PARAM_TYPE_U32
2018-12-03 10:58:59 +03:00
# define DEVLINK_PARAM_GENERIC_FW_LOAD_POLICY_NAME "fw_load_policy"
# define DEVLINK_PARAM_GENERIC_FW_LOAD_POLICY_TYPE DEVLINK_PARAM_TYPE_U8
2019-09-09 02:54:18 +03:00
# define DEVLINK_PARAM_GENERIC_RESET_DEV_ON_DRV_PROBE_NAME \
" reset_dev_on_drv_probe "
# define DEVLINK_PARAM_GENERIC_RESET_DEV_ON_DRV_PROBE_TYPE DEVLINK_PARAM_TYPE_U8
2019-11-09 02:45:20 +03:00
# define DEVLINK_PARAM_GENERIC_ENABLE_ROCE_NAME "enable_roce"
# define DEVLINK_PARAM_GENERIC_ENABLE_ROCE_TYPE DEVLINK_PARAM_TYPE_BOOL
2020-10-07 09:00:53 +03:00
# define DEVLINK_PARAM_GENERIC_ENABLE_REMOTE_DEV_RESET_NAME "enable_remote_dev_reset"
# define DEVLINK_PARAM_GENERIC_ENABLE_REMOTE_DEV_RESET_TYPE DEVLINK_PARAM_TYPE_BOOL
2021-08-10 16:24:15 +03:00
# define DEVLINK_PARAM_GENERIC_ENABLE_ETH_NAME "enable_eth"
# define DEVLINK_PARAM_GENERIC_ENABLE_ETH_TYPE DEVLINK_PARAM_TYPE_BOOL
2021-08-10 16:24:16 +03:00
# define DEVLINK_PARAM_GENERIC_ENABLE_RDMA_NAME "enable_rdma"
# define DEVLINK_PARAM_GENERIC_ENABLE_RDMA_TYPE DEVLINK_PARAM_TYPE_BOOL
2021-08-10 16:24:17 +03:00
# define DEVLINK_PARAM_GENERIC_ENABLE_VNET_NAME "enable_vnet"
# define DEVLINK_PARAM_GENERIC_ENABLE_VNET_TYPE DEVLINK_PARAM_TYPE_BOOL
2021-10-19 02:16:01 +03:00
# define DEVLINK_PARAM_GENERIC_ENABLE_IWARP_NAME "enable_iwarp"
# define DEVLINK_PARAM_GENERIC_ENABLE_IWARP_TYPE DEVLINK_PARAM_TYPE_BOOL
2021-12-09 13:09:24 +03:00
# define DEVLINK_PARAM_GENERIC_IO_EQ_SIZE_NAME "io_eq_size"
# define DEVLINK_PARAM_GENERIC_IO_EQ_SIZE_TYPE DEVLINK_PARAM_TYPE_U32
2021-12-09 13:09:26 +03:00
# define DEVLINK_PARAM_GENERIC_EVENT_EQ_SIZE_NAME "event_eq_size"
# define DEVLINK_PARAM_GENERIC_EVENT_EQ_SIZE_TYPE DEVLINK_PARAM_TYPE_U32
2018-07-04 14:30:33 +03:00
# define DEVLINK_PARAM_GENERIC(_id, _cmodes, _get, _set, _validate) \
{ \
. id = DEVLINK_PARAM_GENERIC_ID_ # # _id , \
. name = DEVLINK_PARAM_GENERIC_ # # _id # # _NAME , \
. type = DEVLINK_PARAM_GENERIC_ # # _id # # _TYPE , \
. generic = true , \
. supported_cmodes = _cmodes , \
. get = _get , \
. set = _set , \
. validate = _validate , \
}
# define DEVLINK_PARAM_DRIVER(_id, _name, _type, _cmodes, _get, _set, _validate) \
{ \
. id = _id , \
. name = _name , \
. type = _type , \
. supported_cmodes = _cmodes , \
. get = _get , \
. set = _set , \
. validate = _validate , \
}
2019-01-31 21:50:42 +03:00
/* Part number, identifier of board design */
# define DEVLINK_INFO_VERSION_GENERIC_BOARD_ID "board.id"
/* Revision of board design */
# define DEVLINK_INFO_VERSION_GENERIC_BOARD_REV "board.rev"
2019-02-11 06:35:29 +03:00
/* Maker of the board */
# define DEVLINK_INFO_VERSION_GENERIC_BOARD_MANUFACTURE "board.manufacture"
2019-01-31 21:50:42 +03:00
2019-09-04 01:28:03 +03:00
/* Part number, identifier of asic design */
# define DEVLINK_INFO_VERSION_GENERIC_ASIC_ID "asic.id"
/* Revision of asic design */
# define DEVLINK_INFO_VERSION_GENERIC_ASIC_REV "asic.rev"
/* Overall FW version */
# define DEVLINK_INFO_VERSION_GENERIC_FW "fw"
2019-01-31 21:50:42 +03:00
/* Control processor FW version */
# define DEVLINK_INFO_VERSION_GENERIC_FW_MGMT "fw.mgmt"
2020-03-27 12:34:51 +03:00
/* FW interface specification version */
# define DEVLINK_INFO_VERSION_GENERIC_FW_MGMT_API "fw.mgmt.api"
2019-01-31 21:50:42 +03:00
/* Data path microcode controlling high-speed packet processing */
# define DEVLINK_INFO_VERSION_GENERIC_FW_APP "fw.app"
/* UNDI software version */
# define DEVLINK_INFO_VERSION_GENERIC_FW_UNDI "fw.undi"
/* NCSI support/handler version */
# define DEVLINK_INFO_VERSION_GENERIC_FW_NCSI "fw.ncsi"
2020-01-10 01:46:09 +03:00
/* FW parameter set id */
# define DEVLINK_INFO_VERSION_GENERIC_FW_PSID "fw.psid"
2020-01-27 12:56:25 +03:00
/* RoCE FW version */
# define DEVLINK_INFO_VERSION_GENERIC_FW_ROCE "fw.roce"
2020-03-12 04:58:16 +03:00
/* Firmware bundle identifier */
# define DEVLINK_INFO_VERSION_GENERIC_FW_BUNDLE_ID "fw.bundle_id"
2019-01-31 21:50:42 +03:00
2020-09-25 23:46:06 +03:00
/**
* struct devlink_flash_update_params - Flash Update parameters
2020-11-18 22:06:35 +03:00
* @ fw : pointer to the firmware data to update from
2020-09-25 23:46:06 +03:00
* @ component : the flash component to update
*
2020-11-18 22:06:35 +03:00
* With the exception of fw , drivers must opt - in to parameters by
2020-09-25 23:46:06 +03:00
* setting the appropriate bit in the supported_flash_update_params field in
* their devlink_ops structure .
*/
struct devlink_flash_update_params {
2020-11-18 22:06:35 +03:00
const struct firmware * fw ;
2020-09-25 23:46:06 +03:00
const char * component ;
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 23:46:07 +03:00
u32 overwrite_mask ;
2020-09-25 23:46:06 +03:00
} ;
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 23:46:07 +03:00
# define DEVLINK_SUPPORT_FLASH_UPDATE_COMPONENT BIT(0)
# define DEVLINK_SUPPORT_FLASH_UPDATE_OVERWRITE_MASK BIT(1)
2020-09-25 23:46:05 +03:00
2018-07-12 15:13:08 +03:00
struct devlink_region ;
2022-05-04 18:40:37 +03:00
struct devlink_info_req ;
2018-07-12 15:13:08 +03:00
2020-03-26 21:37:08 +03:00
/**
* struct devlink_region_ops - Region operations
* @ name : region name
2020-03-26 21:37:09 +03:00
* @ destructor : callback used to free snapshot memory when deleting
2020-03-26 21:37:16 +03:00
* @ snapshot : callback to request an immediate snapshot . On success ,
* the data variable must be updated to point to the snapshot data .
* The function will be called while the devlink instance lock is
* held .
2020-09-18 22:11:01 +03:00
* @ priv : Pointer to driver private data for the region operation
2020-03-26 21:37:08 +03:00
*/
struct devlink_region_ops {
const char * name ;
2020-03-26 21:37:09 +03:00
void ( * destructor ) ( const void * data ) ;
2020-09-18 22:11:02 +03:00
int ( * snapshot ) ( struct devlink * devlink ,
const struct devlink_region_ops * ops ,
struct netlink_ext_ack * extack ,
2020-03-26 21:37:16 +03:00
u8 * * data ) ;
2020-09-18 22:11:01 +03:00
void * priv ;
2020-03-26 21:37:08 +03:00
} ;
2020-10-04 19:12:54 +03:00
/**
* struct devlink_port_region_ops - Region operations for a port
* @ name : region name
* @ destructor : callback used to free snapshot memory when deleting
* @ snapshot : callback to request an immediate snapshot . On success ,
* the data variable must be updated to point to the snapshot data .
* The function will be called while the devlink instance lock is
* held .
* @ priv : Pointer to driver private data for the region operation
*/
struct devlink_port_region_ops {
const char * name ;
void ( * destructor ) ( const void * data ) ;
int ( * snapshot ) ( struct devlink_port * port ,
const struct devlink_port_region_ops * ops ,
struct netlink_ext_ack * extack ,
u8 * * data ) ;
void * priv ;
} ;
2019-02-07 12:36:32 +03:00
struct devlink_fmsg ;
2019-02-07 12:36:33 +03:00
struct devlink_health_reporter ;
2019-03-03 11:57:30 +03:00
enum devlink_health_reporter_state {
DEVLINK_HEALTH_REPORTER_STATE_HEALTHY ,
DEVLINK_HEALTH_REPORTER_STATE_ERROR ,
} ;
2019-02-07 12:36:33 +03:00
/**
* struct devlink_health_reporter_ops - Reporter operations
* @ name : reporter name
* @ recover : callback to recover from reported error
* if priv_ctx is NULL , run a full recover
* @ dump : callback to dump an object
* if priv_ctx is NULL , run a full dump
* @ diagnose : callback to diagnose the current status
2020-09-15 11:40:57 +03:00
* @ test : callback to trigger a test event
2019-02-07 12:36:33 +03:00
*/
struct devlink_health_reporter_ops {
char * name ;
int ( * recover ) ( struct devlink_health_reporter * reporter ,
2019-10-10 16:18:49 +03:00
void * priv_ctx , struct netlink_ext_ack * extack ) ;
2019-02-07 12:36:33 +03:00
int ( * dump ) ( struct devlink_health_reporter * reporter ,
2019-10-10 16:18:49 +03:00
struct devlink_fmsg * fmsg , void * priv_ctx ,
struct netlink_ext_ack * extack ) ;
2019-02-07 12:36:33 +03:00
int ( * diagnose ) ( struct devlink_health_reporter * reporter ,
2019-10-10 16:18:49 +03:00
struct devlink_fmsg * fmsg ,
struct netlink_ext_ack * extack ) ;
2020-09-15 11:40:57 +03:00
int ( * test ) ( struct devlink_health_reporter * reporter ,
struct netlink_ext_ack * extack ) ;
2019-02-07 12:36:33 +03:00
} ;
2019-02-07 12:36:32 +03:00
2020-09-29 11:15:50 +03:00
/**
* struct devlink_trap_metadata - Packet trap metadata .
* @ trap_name : Trap name .
* @ trap_group_name : Trap group name .
* @ input_dev : Input netdevice .
2021-12-05 07:22:02 +03:00
* @ dev_tracker : refcount tracker for @ input_dev .
2020-09-29 11:15:50 +03:00
* @ fa_cookie : Flow action user cookie .
2020-09-29 11:15:55 +03:00
* @ trap_type : Trap type .
2020-09-29 11:15:50 +03:00
*/
struct devlink_trap_metadata {
const char * trap_name ;
const char * trap_group_name ;
2021-12-05 07:22:02 +03:00
2020-09-29 11:15:50 +03:00
struct net_device * input_dev ;
2021-12-05 07:22:02 +03:00
netdevice_tracker dev_tracker ;
2020-09-29 11:15:50 +03:00
const struct flow_action_cookie * fa_cookie ;
2020-09-29 11:15:55 +03:00
enum devlink_trap_type trap_type ;
2020-09-29 11:15:50 +03:00
} ;
2020-03-30 22:38:18 +03:00
/**
* struct devlink_trap_policer - Immutable packet trap policer attributes .
* @ id : Policer identifier .
* @ init_rate : Initial rate in packets / sec .
* @ init_burst : Initial burst size in packets .
* @ max_rate : Maximum rate .
* @ min_rate : Minimum rate .
* @ max_burst : Maximum burst size .
* @ min_burst : Minimum burst size .
*
* Describes immutable attributes of packet trap policers that drivers register
* with devlink .
*/
struct devlink_trap_policer {
u32 id ;
u64 init_rate ;
u64 init_burst ;
u64 max_rate ;
u64 min_rate ;
u64 max_burst ;
u64 min_burst ;
} ;
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 16:28:17 +03:00
/**
* struct devlink_trap_group - Immutable packet trap group attributes .
* @ name : Trap group name .
* @ id : Trap group identifier .
* @ generic : Whether the trap group is generic or not .
2020-03-30 22:38:21 +03:00
* @ init_policer_id : Initial policer identifier .
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 16:28:17 +03:00
*
* Describes immutable attributes of packet trap groups that drivers register
* with devlink .
*/
struct devlink_trap_group {
const char * name ;
u16 id ;
bool generic ;
2020-03-30 22:38:21 +03:00
u32 init_policer_id ;
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 16:28:17 +03:00
} ;
# define DEVLINK_TRAP_METADATA_TYPE_F_IN_PORT BIT(0)
2020-02-25 13:45:19 +03:00
# define DEVLINK_TRAP_METADATA_TYPE_F_FA_COOKIE BIT(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 16:28:17 +03:00
/**
* struct devlink_trap - Immutable packet trap attributes .
* @ type : Trap type .
* @ init_action : Initial trap action .
* @ generic : Whether the trap is generic or not .
* @ id : Trap identifier .
* @ name : Trap name .
2020-03-22 21:48:30 +03:00
* @ init_group_id : Initial group identifier .
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 16:28:17 +03:00
* @ metadata_cap : Metadata types that can be provided by the trap .
*
* Describes immutable attributes of packet traps that drivers register with
* devlink .
*/
struct devlink_trap {
enum devlink_trap_type type ;
enum devlink_trap_action init_action ;
bool generic ;
u16 id ;
const char * name ;
2020-03-22 21:48:30 +03:00
u16 init_group_id ;
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 16:28:17 +03:00
u32 metadata_cap ;
} ;
2019-08-17 16:28:19 +03:00
/* All traps must be documented in
2020-01-10 01:46:10 +03:00
* Documentation / networking / devlink / devlink - trap . rst
2019-08-17 16:28:19 +03: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 16:28:17 +03:00
enum devlink_trap_generic_id {
2019-08-17 16:28:18 +03:00
DEVLINK_TRAP_GENERIC_ID_SMAC_MC ,
DEVLINK_TRAP_GENERIC_ID_VLAN_TAG_MISMATCH ,
DEVLINK_TRAP_GENERIC_ID_INGRESS_VLAN_FILTER ,
DEVLINK_TRAP_GENERIC_ID_INGRESS_STP_FILTER ,
DEVLINK_TRAP_GENERIC_ID_EMPTY_TX_LIST ,
DEVLINK_TRAP_GENERIC_ID_PORT_LOOPBACK_FILTER ,
DEVLINK_TRAP_GENERIC_ID_BLACKHOLE_ROUTE ,
DEVLINK_TRAP_GENERIC_ID_TTL_ERROR ,
DEVLINK_TRAP_GENERIC_ID_TAIL_DROP ,
2019-11-07 19:42:09 +03:00
DEVLINK_TRAP_GENERIC_ID_NON_IP_PACKET ,
DEVLINK_TRAP_GENERIC_ID_UC_DIP_MC_DMAC ,
DEVLINK_TRAP_GENERIC_ID_DIP_LB ,
DEVLINK_TRAP_GENERIC_ID_SIP_MC ,
DEVLINK_TRAP_GENERIC_ID_SIP_LB ,
DEVLINK_TRAP_GENERIC_ID_CORRUPTED_IP_HDR ,
DEVLINK_TRAP_GENERIC_ID_IPV4_SIP_BC ,
DEVLINK_TRAP_GENERIC_ID_IPV6_MC_DIP_RESERVED_SCOPE ,
DEVLINK_TRAP_GENERIC_ID_IPV6_MC_DIP_INTERFACE_LOCAL_SCOPE ,
2019-11-07 19:42:14 +03:00
DEVLINK_TRAP_GENERIC_ID_MTU_ERROR ,
DEVLINK_TRAP_GENERIC_ID_UNRESOLVED_NEIGH ,
DEVLINK_TRAP_GENERIC_ID_RPF ,
DEVLINK_TRAP_GENERIC_ID_REJECT_ROUTE ,
DEVLINK_TRAP_GENERIC_ID_IPV4_LPM_UNICAST_MISS ,
DEVLINK_TRAP_GENERIC_ID_IPV6_LPM_UNICAST_MISS ,
2020-01-19 16:00:48 +03:00
DEVLINK_TRAP_GENERIC_ID_NON_ROUTABLE ,
2020-01-19 16:00:54 +03:00
DEVLINK_TRAP_GENERIC_ID_DECAP_ERROR ,
2020-01-19 16:00:58 +03:00
DEVLINK_TRAP_GENERIC_ID_OVERLAY_SMAC_MC ,
2020-02-24 10:35:47 +03:00
DEVLINK_TRAP_GENERIC_ID_INGRESS_FLOW_ACTION_DROP ,
DEVLINK_TRAP_GENERIC_ID_EGRESS_FLOW_ACTION_DROP ,
2020-05-29 21:36:41 +03:00
DEVLINK_TRAP_GENERIC_ID_STP ,
DEVLINK_TRAP_GENERIC_ID_LACP ,
DEVLINK_TRAP_GENERIC_ID_LLDP ,
DEVLINK_TRAP_GENERIC_ID_IGMP_QUERY ,
DEVLINK_TRAP_GENERIC_ID_IGMP_V1_REPORT ,
DEVLINK_TRAP_GENERIC_ID_IGMP_V2_REPORT ,
DEVLINK_TRAP_GENERIC_ID_IGMP_V3_REPORT ,
DEVLINK_TRAP_GENERIC_ID_IGMP_V2_LEAVE ,
DEVLINK_TRAP_GENERIC_ID_MLD_QUERY ,
DEVLINK_TRAP_GENERIC_ID_MLD_V1_REPORT ,
DEVLINK_TRAP_GENERIC_ID_MLD_V2_REPORT ,
DEVLINK_TRAP_GENERIC_ID_MLD_V1_DONE ,
2020-05-29 21:36:42 +03:00
DEVLINK_TRAP_GENERIC_ID_IPV4_DHCP ,
DEVLINK_TRAP_GENERIC_ID_IPV6_DHCP ,
DEVLINK_TRAP_GENERIC_ID_ARP_REQUEST ,
DEVLINK_TRAP_GENERIC_ID_ARP_RESPONSE ,
DEVLINK_TRAP_GENERIC_ID_ARP_OVERLAY ,
DEVLINK_TRAP_GENERIC_ID_IPV6_NEIGH_SOLICIT ,
DEVLINK_TRAP_GENERIC_ID_IPV6_NEIGH_ADVERT ,
DEVLINK_TRAP_GENERIC_ID_IPV4_BFD ,
DEVLINK_TRAP_GENERIC_ID_IPV6_BFD ,
DEVLINK_TRAP_GENERIC_ID_IPV4_OSPF ,
DEVLINK_TRAP_GENERIC_ID_IPV6_OSPF ,
DEVLINK_TRAP_GENERIC_ID_IPV4_BGP ,
DEVLINK_TRAP_GENERIC_ID_IPV6_BGP ,
DEVLINK_TRAP_GENERIC_ID_IPV4_VRRP ,
DEVLINK_TRAP_GENERIC_ID_IPV6_VRRP ,
DEVLINK_TRAP_GENERIC_ID_IPV4_PIM ,
DEVLINK_TRAP_GENERIC_ID_IPV6_PIM ,
DEVLINK_TRAP_GENERIC_ID_UC_LB ,
DEVLINK_TRAP_GENERIC_ID_LOCAL_ROUTE ,
DEVLINK_TRAP_GENERIC_ID_EXTERNAL_ROUTE ,
DEVLINK_TRAP_GENERIC_ID_IPV6_UC_DIP_LINK_LOCAL_SCOPE ,
DEVLINK_TRAP_GENERIC_ID_IPV6_DIP_ALL_NODES ,
DEVLINK_TRAP_GENERIC_ID_IPV6_DIP_ALL_ROUTERS ,
DEVLINK_TRAP_GENERIC_ID_IPV6_ROUTER_SOLICIT ,
DEVLINK_TRAP_GENERIC_ID_IPV6_ROUTER_ADVERT ,
DEVLINK_TRAP_GENERIC_ID_IPV6_REDIRECT ,
DEVLINK_TRAP_GENERIC_ID_IPV4_ROUTER_ALERT ,
DEVLINK_TRAP_GENERIC_ID_IPV6_ROUTER_ALERT ,
DEVLINK_TRAP_GENERIC_ID_PTP_EVENT ,
DEVLINK_TRAP_GENERIC_ID_PTP_GENERAL ,
2020-05-29 21:36:43 +03:00
DEVLINK_TRAP_GENERIC_ID_FLOW_ACTION_SAMPLE ,
DEVLINK_TRAP_GENERIC_ID_FLOW_ACTION_TRAP ,
2020-08-03 19:11:33 +03:00
DEVLINK_TRAP_GENERIC_ID_EARLY_DROP ,
2020-10-01 18:11:45 +03:00
DEVLINK_TRAP_GENERIC_ID_VXLAN_PARSING ,
DEVLINK_TRAP_GENERIC_ID_LLC_SNAP_PARSING ,
DEVLINK_TRAP_GENERIC_ID_VLAN_PARSING ,
DEVLINK_TRAP_GENERIC_ID_PPPOE_PPP_PARSING ,
DEVLINK_TRAP_GENERIC_ID_MPLS_PARSING ,
DEVLINK_TRAP_GENERIC_ID_ARP_PARSING ,
DEVLINK_TRAP_GENERIC_ID_IP_1_PARSING ,
DEVLINK_TRAP_GENERIC_ID_IP_N_PARSING ,
DEVLINK_TRAP_GENERIC_ID_GRE_PARSING ,
DEVLINK_TRAP_GENERIC_ID_UDP_PARSING ,
DEVLINK_TRAP_GENERIC_ID_TCP_PARSING ,
DEVLINK_TRAP_GENERIC_ID_IPSEC_PARSING ,
DEVLINK_TRAP_GENERIC_ID_SCTP_PARSING ,
DEVLINK_TRAP_GENERIC_ID_DCCP_PARSING ,
DEVLINK_TRAP_GENERIC_ID_GTP_PARSING ,
DEVLINK_TRAP_GENERIC_ID_ESP_PARSING ,
2020-11-23 10:12:28 +03:00
DEVLINK_TRAP_GENERIC_ID_BLACKHOLE_NEXTHOP ,
2021-01-27 02:24:06 +03:00
DEVLINK_TRAP_GENERIC_ID_DMAC_FILTER ,
2019-08-17 16:28:18 +03: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 16:28:17 +03:00
/* Add new generic trap IDs above */
__DEVLINK_TRAP_GENERIC_ID_MAX ,
DEVLINK_TRAP_GENERIC_ID_MAX = __DEVLINK_TRAP_GENERIC_ID_MAX - 1 ,
} ;
2019-08-17 16:28:19 +03:00
/* All trap groups must be documented in
2020-01-10 01:46:10 +03:00
* Documentation / networking / devlink / devlink - trap . rst
2019-08-17 16:28:19 +03: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 16:28:17 +03:00
enum devlink_trap_group_generic_id {
2019-08-17 16:28:18 +03:00
DEVLINK_TRAP_GROUP_GENERIC_ID_L2_DROPS ,
DEVLINK_TRAP_GROUP_GENERIC_ID_L3_DROPS ,
2020-05-29 21:36:36 +03:00
DEVLINK_TRAP_GROUP_GENERIC_ID_L3_EXCEPTIONS ,
2019-08-17 16:28:18 +03:00
DEVLINK_TRAP_GROUP_GENERIC_ID_BUFFER_DROPS ,
2020-01-19 16:00:54 +03:00
DEVLINK_TRAP_GROUP_GENERIC_ID_TUNNEL_DROPS ,
2020-02-24 10:35:47 +03:00
DEVLINK_TRAP_GROUP_GENERIC_ID_ACL_DROPS ,
2020-05-29 21:36:41 +03:00
DEVLINK_TRAP_GROUP_GENERIC_ID_STP ,
DEVLINK_TRAP_GROUP_GENERIC_ID_LACP ,
DEVLINK_TRAP_GROUP_GENERIC_ID_LLDP ,
DEVLINK_TRAP_GROUP_GENERIC_ID_MC_SNOOPING ,
2020-05-29 21:36:42 +03:00
DEVLINK_TRAP_GROUP_GENERIC_ID_DHCP ,
DEVLINK_TRAP_GROUP_GENERIC_ID_NEIGH_DISCOVERY ,
DEVLINK_TRAP_GROUP_GENERIC_ID_BFD ,
DEVLINK_TRAP_GROUP_GENERIC_ID_OSPF ,
DEVLINK_TRAP_GROUP_GENERIC_ID_BGP ,
DEVLINK_TRAP_GROUP_GENERIC_ID_VRRP ,
DEVLINK_TRAP_GROUP_GENERIC_ID_PIM ,
DEVLINK_TRAP_GROUP_GENERIC_ID_UC_LB ,
DEVLINK_TRAP_GROUP_GENERIC_ID_LOCAL_DELIVERY ,
2020-07-29 12:26:44 +03:00
DEVLINK_TRAP_GROUP_GENERIC_ID_EXTERNAL_DELIVERY ,
2020-05-29 21:36:42 +03:00
DEVLINK_TRAP_GROUP_GENERIC_ID_IPV6 ,
DEVLINK_TRAP_GROUP_GENERIC_ID_PTP_EVENT ,
DEVLINK_TRAP_GROUP_GENERIC_ID_PTP_GENERAL ,
2020-05-29 21:36:43 +03:00
DEVLINK_TRAP_GROUP_GENERIC_ID_ACL_SAMPLE ,
DEVLINK_TRAP_GROUP_GENERIC_ID_ACL_TRAP ,
2020-10-01 18:11:45 +03:00
DEVLINK_TRAP_GROUP_GENERIC_ID_PARSER_ERROR_DROPS ,
2019-08-17 16:28:18 +03: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 16:28:17 +03:00
/* Add new generic trap group IDs above */
__DEVLINK_TRAP_GROUP_GENERIC_ID_MAX ,
DEVLINK_TRAP_GROUP_GENERIC_ID_MAX =
__DEVLINK_TRAP_GROUP_GENERIC_ID_MAX - 1 ,
} ;
2019-08-17 16:28:18 +03:00
# define DEVLINK_TRAP_GENERIC_NAME_SMAC_MC \
" source_mac_is_multicast "
# define DEVLINK_TRAP_GENERIC_NAME_VLAN_TAG_MISMATCH \
" vlan_tag_mismatch "
# define DEVLINK_TRAP_GENERIC_NAME_INGRESS_VLAN_FILTER \
" ingress_vlan_filter "
# define DEVLINK_TRAP_GENERIC_NAME_INGRESS_STP_FILTER \
" ingress_spanning_tree_filter "
# define DEVLINK_TRAP_GENERIC_NAME_EMPTY_TX_LIST \
" port_list_is_empty "
# define DEVLINK_TRAP_GENERIC_NAME_PORT_LOOPBACK_FILTER \
" port_loopback_filter "
# define DEVLINK_TRAP_GENERIC_NAME_BLACKHOLE_ROUTE \
" blackhole_route "
# define DEVLINK_TRAP_GENERIC_NAME_TTL_ERROR \
" ttl_value_is_too_small "
# define DEVLINK_TRAP_GENERIC_NAME_TAIL_DROP \
" tail_drop "
2019-11-07 19:42:09 +03:00
# define DEVLINK_TRAP_GENERIC_NAME_NON_IP_PACKET \
" non_ip "
# define DEVLINK_TRAP_GENERIC_NAME_UC_DIP_MC_DMAC \
" uc_dip_over_mc_dmac "
# define DEVLINK_TRAP_GENERIC_NAME_DIP_LB \
" dip_is_loopback_address "
# define DEVLINK_TRAP_GENERIC_NAME_SIP_MC \
" sip_is_mc "
# define DEVLINK_TRAP_GENERIC_NAME_SIP_LB \
" sip_is_loopback_address "
# define DEVLINK_TRAP_GENERIC_NAME_CORRUPTED_IP_HDR \
" ip_header_corrupted "
# define DEVLINK_TRAP_GENERIC_NAME_IPV4_SIP_BC \
" ipv4_sip_is_limited_bc "
# define DEVLINK_TRAP_GENERIC_NAME_IPV6_MC_DIP_RESERVED_SCOPE \
" ipv6_mc_dip_reserved_scope "
# define DEVLINK_TRAP_GENERIC_NAME_IPV6_MC_DIP_INTERFACE_LOCAL_SCOPE \
" ipv6_mc_dip_interface_local_scope "
2019-11-07 19:42:14 +03:00
# define DEVLINK_TRAP_GENERIC_NAME_MTU_ERROR \
" mtu_value_is_too_small "
# define DEVLINK_TRAP_GENERIC_NAME_UNRESOLVED_NEIGH \
" unresolved_neigh "
# define DEVLINK_TRAP_GENERIC_NAME_RPF \
" mc_reverse_path_forwarding "
# define DEVLINK_TRAP_GENERIC_NAME_REJECT_ROUTE \
" reject_route "
# define DEVLINK_TRAP_GENERIC_NAME_IPV4_LPM_UNICAST_MISS \
" ipv4_lpm_miss "
# define DEVLINK_TRAP_GENERIC_NAME_IPV6_LPM_UNICAST_MISS \
" ipv6_lpm_miss "
2020-01-19 16:00:48 +03:00
# define DEVLINK_TRAP_GENERIC_NAME_NON_ROUTABLE \
" non_routable_packet "
2020-01-19 16:00:54 +03:00
# define DEVLINK_TRAP_GENERIC_NAME_DECAP_ERROR \
" decap_error "
2020-01-19 16:00:58 +03:00
# define DEVLINK_TRAP_GENERIC_NAME_OVERLAY_SMAC_MC \
" overlay_smac_is_mc "
2020-02-24 10:35:47 +03:00
# define DEVLINK_TRAP_GENERIC_NAME_INGRESS_FLOW_ACTION_DROP \
" ingress_flow_action_drop "
# define DEVLINK_TRAP_GENERIC_NAME_EGRESS_FLOW_ACTION_DROP \
" egress_flow_action_drop "
2020-05-29 21:36:41 +03:00
# define DEVLINK_TRAP_GENERIC_NAME_STP \
" stp "
# define DEVLINK_TRAP_GENERIC_NAME_LACP \
" lacp "
# define DEVLINK_TRAP_GENERIC_NAME_LLDP \
" lldp "
# define DEVLINK_TRAP_GENERIC_NAME_IGMP_QUERY \
" igmp_query "
# define DEVLINK_TRAP_GENERIC_NAME_IGMP_V1_REPORT \
" igmp_v1_report "
# define DEVLINK_TRAP_GENERIC_NAME_IGMP_V2_REPORT \
" igmp_v2_report "
# define DEVLINK_TRAP_GENERIC_NAME_IGMP_V3_REPORT \
" igmp_v3_report "
# define DEVLINK_TRAP_GENERIC_NAME_IGMP_V2_LEAVE \
" igmp_v2_leave "
# define DEVLINK_TRAP_GENERIC_NAME_MLD_QUERY \
" mld_query "
# define DEVLINK_TRAP_GENERIC_NAME_MLD_V1_REPORT \
" mld_v1_report "
# define DEVLINK_TRAP_GENERIC_NAME_MLD_V2_REPORT \
" mld_v2_report "
# define DEVLINK_TRAP_GENERIC_NAME_MLD_V1_DONE \
" mld_v1_done "
2020-05-29 21:36:42 +03:00
# define DEVLINK_TRAP_GENERIC_NAME_IPV4_DHCP \
" ipv4_dhcp "
# define DEVLINK_TRAP_GENERIC_NAME_IPV6_DHCP \
" ipv6_dhcp "
# define DEVLINK_TRAP_GENERIC_NAME_ARP_REQUEST \
" arp_request "
# define DEVLINK_TRAP_GENERIC_NAME_ARP_RESPONSE \
" arp_response "
# define DEVLINK_TRAP_GENERIC_NAME_ARP_OVERLAY \
" arp_overlay "
# define DEVLINK_TRAP_GENERIC_NAME_IPV6_NEIGH_SOLICIT \
" ipv6_neigh_solicit "
# define DEVLINK_TRAP_GENERIC_NAME_IPV6_NEIGH_ADVERT \
" ipv6_neigh_advert "
# define DEVLINK_TRAP_GENERIC_NAME_IPV4_BFD \
" ipv4_bfd "
# define DEVLINK_TRAP_GENERIC_NAME_IPV6_BFD \
" ipv6_bfd "
# define DEVLINK_TRAP_GENERIC_NAME_IPV4_OSPF \
" ipv4_ospf "
# define DEVLINK_TRAP_GENERIC_NAME_IPV6_OSPF \
" ipv6_ospf "
# define DEVLINK_TRAP_GENERIC_NAME_IPV4_BGP \
" ipv4_bgp "
# define DEVLINK_TRAP_GENERIC_NAME_IPV6_BGP \
" ipv6_bgp "
# define DEVLINK_TRAP_GENERIC_NAME_IPV4_VRRP \
" ipv4_vrrp "
# define DEVLINK_TRAP_GENERIC_NAME_IPV6_VRRP \
" ipv6_vrrp "
# define DEVLINK_TRAP_GENERIC_NAME_IPV4_PIM \
" ipv4_pim "
# define DEVLINK_TRAP_GENERIC_NAME_IPV6_PIM \
" ipv6_pim "
# define DEVLINK_TRAP_GENERIC_NAME_UC_LB \
" uc_loopback "
# define DEVLINK_TRAP_GENERIC_NAME_LOCAL_ROUTE \
" local_route "
# define DEVLINK_TRAP_GENERIC_NAME_EXTERNAL_ROUTE \
" external_route "
# define DEVLINK_TRAP_GENERIC_NAME_IPV6_UC_DIP_LINK_LOCAL_SCOPE \
" ipv6_uc_dip_link_local_scope "
# define DEVLINK_TRAP_GENERIC_NAME_IPV6_DIP_ALL_NODES \
" ipv6_dip_all_nodes "
# define DEVLINK_TRAP_GENERIC_NAME_IPV6_DIP_ALL_ROUTERS \
" ipv6_dip_all_routers "
# define DEVLINK_TRAP_GENERIC_NAME_IPV6_ROUTER_SOLICIT \
" ipv6_router_solicit "
# define DEVLINK_TRAP_GENERIC_NAME_IPV6_ROUTER_ADVERT \
" ipv6_router_advert "
# define DEVLINK_TRAP_GENERIC_NAME_IPV6_REDIRECT \
" ipv6_redirect "
# define DEVLINK_TRAP_GENERIC_NAME_IPV4_ROUTER_ALERT \
" ipv4_router_alert "
# define DEVLINK_TRAP_GENERIC_NAME_IPV6_ROUTER_ALERT \
" ipv6_router_alert "
# define DEVLINK_TRAP_GENERIC_NAME_PTP_EVENT \
" ptp_event "
# define DEVLINK_TRAP_GENERIC_NAME_PTP_GENERAL \
" ptp_general "
2020-05-29 21:36:43 +03:00
# define DEVLINK_TRAP_GENERIC_NAME_FLOW_ACTION_SAMPLE \
" flow_action_sample "
# define DEVLINK_TRAP_GENERIC_NAME_FLOW_ACTION_TRAP \
" flow_action_trap "
2020-08-03 19:11:33 +03:00
# define DEVLINK_TRAP_GENERIC_NAME_EARLY_DROP \
" early_drop "
2020-10-01 18:11:45 +03:00
# define DEVLINK_TRAP_GENERIC_NAME_VXLAN_PARSING \
" vxlan_parsing "
# define DEVLINK_TRAP_GENERIC_NAME_LLC_SNAP_PARSING \
" llc_snap_parsing "
# define DEVLINK_TRAP_GENERIC_NAME_VLAN_PARSING \
" vlan_parsing "
# define DEVLINK_TRAP_GENERIC_NAME_PPPOE_PPP_PARSING \
" pppoe_ppp_parsing "
# define DEVLINK_TRAP_GENERIC_NAME_MPLS_PARSING \
" mpls_parsing "
# define DEVLINK_TRAP_GENERIC_NAME_ARP_PARSING \
" arp_parsing "
# define DEVLINK_TRAP_GENERIC_NAME_IP_1_PARSING \
" ip_1_parsing "
# define DEVLINK_TRAP_GENERIC_NAME_IP_N_PARSING \
" ip_n_parsing "
# define DEVLINK_TRAP_GENERIC_NAME_GRE_PARSING \
" gre_parsing "
# define DEVLINK_TRAP_GENERIC_NAME_UDP_PARSING \
" udp_parsing "
# define DEVLINK_TRAP_GENERIC_NAME_TCP_PARSING \
" tcp_parsing "
# define DEVLINK_TRAP_GENERIC_NAME_IPSEC_PARSING \
" ipsec_parsing "
# define DEVLINK_TRAP_GENERIC_NAME_SCTP_PARSING \
" sctp_parsing "
# define DEVLINK_TRAP_GENERIC_NAME_DCCP_PARSING \
" dccp_parsing "
# define DEVLINK_TRAP_GENERIC_NAME_GTP_PARSING \
" gtp_parsing "
# define DEVLINK_TRAP_GENERIC_NAME_ESP_PARSING \
" esp_parsing "
2020-11-23 10:12:28 +03:00
# define DEVLINK_TRAP_GENERIC_NAME_BLACKHOLE_NEXTHOP \
" blackhole_nexthop "
2021-01-27 02:24:06 +03:00
# define DEVLINK_TRAP_GENERIC_NAME_DMAC_FILTER \
2021-02-09 13:59:55 +03:00
" dmac_filter "
2019-08-17 16:28:18 +03:00
# define DEVLINK_TRAP_GROUP_GENERIC_NAME_L2_DROPS \
" l2_drops "
# define DEVLINK_TRAP_GROUP_GENERIC_NAME_L3_DROPS \
" l3_drops "
2020-05-29 21:36:36 +03:00
# define DEVLINK_TRAP_GROUP_GENERIC_NAME_L3_EXCEPTIONS \
" l3_exceptions "
2019-08-17 16:28:18 +03:00
# define DEVLINK_TRAP_GROUP_GENERIC_NAME_BUFFER_DROPS \
" buffer_drops "
2020-01-19 16:00:54 +03:00
# define DEVLINK_TRAP_GROUP_GENERIC_NAME_TUNNEL_DROPS \
" tunnel_drops "
2020-02-24 10:35:47 +03:00
# define DEVLINK_TRAP_GROUP_GENERIC_NAME_ACL_DROPS \
" acl_drops "
2020-05-29 21:36:41 +03:00
# define DEVLINK_TRAP_GROUP_GENERIC_NAME_STP \
" stp "
# define DEVLINK_TRAP_GROUP_GENERIC_NAME_LACP \
" lacp "
# define DEVLINK_TRAP_GROUP_GENERIC_NAME_LLDP \
" lldp "
# define DEVLINK_TRAP_GROUP_GENERIC_NAME_MC_SNOOPING \
" mc_snooping "
2020-05-29 21:36:42 +03:00
# define DEVLINK_TRAP_GROUP_GENERIC_NAME_DHCP \
" dhcp "
# define DEVLINK_TRAP_GROUP_GENERIC_NAME_NEIGH_DISCOVERY \
" neigh_discovery "
# define DEVLINK_TRAP_GROUP_GENERIC_NAME_BFD \
" bfd "
# define DEVLINK_TRAP_GROUP_GENERIC_NAME_OSPF \
" ospf "
# define DEVLINK_TRAP_GROUP_GENERIC_NAME_BGP \
" bgp "
# define DEVLINK_TRAP_GROUP_GENERIC_NAME_VRRP \
" vrrp "
# define DEVLINK_TRAP_GROUP_GENERIC_NAME_PIM \
" pim "
# define DEVLINK_TRAP_GROUP_GENERIC_NAME_UC_LB \
" uc_loopback "
# define DEVLINK_TRAP_GROUP_GENERIC_NAME_LOCAL_DELIVERY \
" local_delivery "
2020-07-29 12:26:44 +03:00
# define DEVLINK_TRAP_GROUP_GENERIC_NAME_EXTERNAL_DELIVERY \
" external_delivery "
2020-05-29 21:36:42 +03:00
# define DEVLINK_TRAP_GROUP_GENERIC_NAME_IPV6 \
" ipv6 "
# define DEVLINK_TRAP_GROUP_GENERIC_NAME_PTP_EVENT \
" ptp_event "
# define DEVLINK_TRAP_GROUP_GENERIC_NAME_PTP_GENERAL \
" ptp_general "
2020-05-29 21:36:43 +03:00
# define DEVLINK_TRAP_GROUP_GENERIC_NAME_ACL_SAMPLE \
" acl_sample "
# define DEVLINK_TRAP_GROUP_GENERIC_NAME_ACL_TRAP \
" acl_trap "
2020-10-01 18:11:45 +03:00
# define DEVLINK_TRAP_GROUP_GENERIC_NAME_PARSER_ERROR_DROPS \
" parser_error_drops "
2019-08-17 16:28:18 +03:00
2020-03-22 21:48:30 +03:00
# define DEVLINK_TRAP_GENERIC(_type, _init_action, _id, _group_id, \
_metadata_cap ) \
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 16:28:17 +03:00
{ \
. type = DEVLINK_TRAP_TYPE_ # # _type , \
. init_action = DEVLINK_TRAP_ACTION_ # # _init_action , \
. generic = true , \
. id = DEVLINK_TRAP_GENERIC_ID_ # # _id , \
. name = DEVLINK_TRAP_GENERIC_NAME_ # # _id , \
2020-03-22 21:48:30 +03:00
. init_group_id = _group_id , \
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 16:28:17 +03:00
. metadata_cap = _metadata_cap , \
}
2020-03-22 21:48:30 +03:00
# define DEVLINK_TRAP_DRIVER(_type, _init_action, _id, _name, _group_id, \
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 16:28:17 +03:00
_metadata_cap ) \
{ \
. type = DEVLINK_TRAP_TYPE_ # # _type , \
. init_action = DEVLINK_TRAP_ACTION_ # # _init_action , \
. generic = false , \
. id = _id , \
. name = _name , \
2020-03-22 21:48:30 +03:00
. init_group_id = _group_id , \
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 16:28:17 +03:00
. metadata_cap = _metadata_cap , \
}
2020-03-30 22:38:21 +03:00
# define DEVLINK_TRAP_GROUP_GENERIC(_id, _policer_id) \
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 16:28:17 +03:00
{ \
. name = DEVLINK_TRAP_GROUP_GENERIC_NAME_ # # _id , \
. id = DEVLINK_TRAP_GROUP_GENERIC_ID_ # # _id , \
. generic = true , \
2020-03-30 22:38:21 +03:00
. init_policer_id = _policer_id , \
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 16:28:17 +03:00
}
2020-03-30 22:38:18 +03:00
# define DEVLINK_TRAP_POLICER(_id, _rate, _burst, _max_rate, _min_rate, \
_max_burst , _min_burst ) \
{ \
. id = _id , \
. init_rate = _rate , \
. init_burst = _burst , \
. max_rate = _max_rate , \
. min_rate = _min_rate , \
. max_burst = _max_burst , \
. min_burst = _min_burst , \
}
2021-10-12 16:15:24 +03:00
enum {
/* device supports reload operations */
DEVLINK_F_RELOAD = 1UL < < 0 ,
} ;
2016-02-26 19:32:23 +03:00
struct devlink_ops {
2020-09-25 23:46:05 +03:00
/**
* @ supported_flash_update_params :
* mask of parameters supported by the driver ' s . flash_update
* implemementation .
*/
u32 supported_flash_update_params ;
2020-10-07 09:00:43 +03:00
unsigned long reload_actions ;
2020-10-07 09:00:44 +03:00
unsigned long reload_limits ;
2019-10-03 12:49:39 +03:00
int ( * reload_down ) ( struct devlink * devlink , bool netns_change ,
2020-10-07 09:00:44 +03:00
enum devlink_reload_action action ,
enum devlink_reload_limit limit ,
struct netlink_ext_ack * extack ) ;
2020-10-07 09:00:43 +03:00
int ( * reload_up ) ( struct devlink * devlink , enum devlink_reload_action action ,
2020-10-07 09:00:44 +03:00
enum devlink_reload_limit limit , u32 * actions_performed ,
struct netlink_ext_ack * extack ) ;
2016-02-26 19:32:23 +03:00
int ( * port_type_set ) ( struct devlink_port * devlink_port ,
enum devlink_port_type port_type ) ;
2022-03-15 09:00:09 +03:00
int ( * port_split ) ( struct devlink * devlink , struct devlink_port * port ,
2018-06-05 18:14:09 +03:00
unsigned int count , struct netlink_ext_ack * extack ) ;
2022-03-15 09:00:09 +03:00
int ( * port_unsplit ) ( struct devlink * devlink , struct devlink_port * port ,
2018-06-05 18:14:09 +03:00
struct netlink_ext_ack * extack ) ;
2016-04-14 19:19:13 +03:00
int ( * sb_pool_get ) ( struct devlink * devlink , unsigned int sb_index ,
u16 pool_index ,
struct devlink_sb_pool_info * pool_info ) ;
int ( * sb_pool_set ) ( struct devlink * devlink , unsigned int sb_index ,
u16 pool_index , u32 size ,
2019-04-22 15:08:39 +03:00
enum devlink_sb_threshold_type threshold_type ,
struct netlink_ext_ack * extack ) ;
2016-04-14 19:19:13 +03:00
int ( * sb_port_pool_get ) ( struct devlink_port * devlink_port ,
unsigned int sb_index , u16 pool_index ,
u32 * p_threshold ) ;
int ( * sb_port_pool_set ) ( struct devlink_port * devlink_port ,
unsigned int sb_index , u16 pool_index ,
2019-04-22 15:08:39 +03:00
u32 threshold , struct netlink_ext_ack * extack ) ;
2016-04-14 19:19:13 +03:00
int ( * sb_tc_pool_bind_get ) ( struct devlink_port * devlink_port ,
unsigned int sb_index ,
u16 tc_index ,
enum devlink_sb_pool_type pool_type ,
u16 * p_pool_index , u32 * p_threshold ) ;
int ( * sb_tc_pool_bind_set ) ( struct devlink_port * devlink_port ,
unsigned int sb_index ,
u16 tc_index ,
enum devlink_sb_pool_type pool_type ,
2019-04-22 15:08:39 +03:00
u16 pool_index , u32 threshold ,
struct netlink_ext_ack * extack ) ;
2016-04-14 19:19:14 +03:00
int ( * sb_occ_snapshot ) ( struct devlink * devlink ,
unsigned int sb_index ) ;
int ( * sb_occ_max_clear ) ( struct devlink * devlink ,
unsigned int sb_index ) ;
int ( * sb_occ_port_pool_get ) ( struct devlink_port * devlink_port ,
unsigned int sb_index , u16 pool_index ,
u32 * p_cur , u32 * p_max ) ;
int ( * sb_occ_tc_port_bind_get ) ( struct devlink_port * devlink_port ,
unsigned int sb_index ,
u16 tc_index ,
enum devlink_sb_pool_type pool_type ,
u32 * p_cur , u32 * p_max ) ;
2016-07-01 14:51:01 +03:00
int ( * eswitch_mode_get ) ( struct devlink * devlink , u16 * p_mode ) ;
2018-08-15 16:02:18 +03:00
int ( * eswitch_mode_set ) ( struct devlink * devlink , u16 mode ,
struct netlink_ext_ack * extack ) ;
2016-11-23 00:09:57 +03:00
int ( * eswitch_inline_mode_get ) ( struct devlink * devlink , u8 * p_inline_mode ) ;
2018-08-15 16:02:18 +03:00
int ( * eswitch_inline_mode_set ) ( struct devlink * devlink , u8 inline_mode ,
struct netlink_ext_ack * extack ) ;
2019-06-12 15:20:11 +03:00
int ( * eswitch_encap_mode_get ) ( struct devlink * devlink ,
enum devlink_eswitch_encap_mode * p_encap_mode ) ;
int ( * eswitch_encap_mode_set ) ( struct devlink * devlink ,
enum devlink_eswitch_encap_mode encap_mode ,
2018-08-15 16:02:18 +03:00
struct netlink_ext_ack * extack ) ;
2019-01-31 21:50:40 +03:00
int ( * info_get ) ( struct devlink * devlink , struct devlink_info_req * req ,
struct netlink_ext_ack * extack ) ;
2020-09-25 23:46:05 +03:00
/**
* @ flash_update : Device flash update function
*
* Used to perform a flash update for the device . The set of
* parameters supported by the driver should be set in
* supported_flash_update_params .
*/
2020-09-25 23:46:06 +03:00
int ( * flash_update ) ( struct devlink * devlink ,
struct devlink_flash_update_params * params ,
2019-02-15 00:40:44 +03:00
struct netlink_ext_ack * extack ) ;
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 16:28:17 +03:00
/**
* @ trap_init : Trap initialization function .
*
* Should be used by device drivers to initialize the trap in the
* underlying device . Drivers should also store the provided trap
* context , so that they could efficiently pass it to
* devlink_trap_report ( ) when the trap is triggered .
*/
int ( * trap_init ) ( struct devlink * devlink ,
const struct devlink_trap * trap , void * trap_ctx ) ;
/**
* @ trap_fini : Trap de - initialization function .
*
* Should be used by device drivers to de - initialize the trap in the
* underlying device .
*/
void ( * trap_fini ) ( struct devlink * devlink ,
const struct devlink_trap * trap , void * trap_ctx ) ;
/**
* @ trap_action_set : Trap action set function .
*/
int ( * trap_action_set ) ( struct devlink * devlink ,
const struct devlink_trap * trap ,
2020-08-03 19:11:34 +03:00
enum devlink_trap_action action ,
struct netlink_ext_ack * extack ) ;
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 16:28:17 +03:00
/**
* @ trap_group_init : Trap group initialization function .
*
* Should be used by device drivers to initialize the trap group in the
* underlying device .
*/
int ( * trap_group_init ) ( struct devlink * devlink ,
const struct devlink_trap_group * group ) ;
2020-03-30 22:38:22 +03:00
/**
* @ trap_group_set : Trap group parameters set function .
*
* Note : @ policer can be NULL when a policer is being unbound from
* @ group .
*/
int ( * trap_group_set ) ( struct devlink * devlink ,
const struct devlink_trap_group * group ,
2020-08-03 19:11:34 +03:00
const struct devlink_trap_policer * policer ,
struct netlink_ext_ack * extack ) ;
2020-10-01 18:11:46 +03:00
/**
* @ trap_group_action_set : Trap group action set function .
*
* If this callback is populated , it will take precedence over looping
* over all traps in a group and calling . trap_action_set ( ) .
*/
int ( * trap_group_action_set ) ( struct devlink * devlink ,
const struct devlink_trap_group * group ,
enum devlink_trap_action action ,
struct netlink_ext_ack * extack ) ;
2021-06-14 16:01:12 +03:00
/**
* @ trap_drop_counter_get : Trap drop counter get function .
*
* Should be used by device drivers to report number of packets
* that have been dropped , and cannot be passed to the devlink
* subsystem by the underlying device .
*/
int ( * trap_drop_counter_get ) ( struct devlink * devlink ,
const struct devlink_trap * trap ,
u64 * p_drops ) ;
2020-03-30 22:38:18 +03:00
/**
* @ trap_policer_init : Trap policer initialization function .
*
* Should be used by device drivers to initialize the trap policer in
* the underlying device .
*/
int ( * trap_policer_init ) ( struct devlink * devlink ,
const struct devlink_trap_policer * policer ) ;
/**
* @ trap_policer_fini : Trap policer de - initialization function .
*
* Should be used by device drivers to de - initialize the trap policer
* in the underlying device .
*/
void ( * trap_policer_fini ) ( struct devlink * devlink ,
const struct devlink_trap_policer * policer ) ;
/**
* @ trap_policer_set : Trap policer parameters set function .
*/
int ( * trap_policer_set ) ( struct devlink * devlink ,
const struct devlink_trap_policer * policer ,
u64 rate , u64 burst ,
struct netlink_ext_ack * extack ) ;
/**
* @ trap_policer_counter_get : Trap policer counter get function .
*
* Should be used by device drivers to report number of packets dropped
* by the policer .
*/
int ( * trap_policer_counter_get ) ( struct devlink * devlink ,
const struct devlink_trap_policer * policer ,
u64 * p_drops ) ;
2020-06-19 06:32:48 +03:00
/**
* @ port_function_hw_addr_get : Port function ' s hardware address get function .
*
* Should be used by device drivers to report the hardware address of a function managed
* by the devlink port . Driver should return - EOPNOTSUPP if it doesn ' t support port
* function handling for a particular port .
*
* Note : @ extack can be NULL when port notifier queries the port function .
*/
2021-08-08 14:41:21 +03:00
int ( * port_function_hw_addr_get ) ( struct devlink_port * port , u8 * hw_addr ,
int * hw_addr_len ,
2020-06-19 06:32:48 +03:00
struct netlink_ext_ack * extack ) ;
2020-06-19 06:32:49 +03:00
/**
* @ port_function_hw_addr_set : Port function ' s hardware address set function .
*
* Should be used by device drivers to set the hardware address of a function managed
* by the devlink port . Driver should return - EOPNOTSUPP if it doesn ' t support port
* function handling for a particular port .
*/
2021-08-08 14:41:21 +03:00
int ( * port_function_hw_addr_set ) ( struct devlink_port * port ,
2020-06-19 06:32:49 +03:00
const u8 * hw_addr , int hw_addr_len ,
struct netlink_ext_ack * extack ) ;
2020-12-12 09:12:14 +03:00
/**
* port_new ( ) - Add a new port function of a specified flavor
* @ devlink : Devlink instance
* @ attrs : attributes of the new port
* @ extack : extack for reporting error messages
* @ new_port_index : index of the new port
*
* Devlink core will call this device driver function upon user request
* to create a new port function of a specified flavor and optional
* attributes
*
* Notes :
* - Called without devlink instance lock being held . Drivers must
* implement own means of synchronization
* - On success , drivers must register a port with devlink core
*
* Return : 0 on success , negative value otherwise .
*/
int ( * port_new ) ( struct devlink * devlink ,
const struct devlink_port_new_attrs * attrs ,
struct netlink_ext_ack * extack ,
unsigned int * new_port_index ) ;
/**
* port_del ( ) - Delete a port function
* @ devlink : Devlink instance
* @ port_index : port function index to delete
* @ extack : extack for reporting error messages
*
* Devlink core will call this device driver function upon user request
* to delete a previously created port function
*
* Notes :
* - Called without devlink instance lock being held . Drivers must
* implement own means of synchronization
* - On success , drivers must unregister the corresponding devlink
* port
*
* Return : 0 on success , negative value otherwise .
*/
int ( * port_del ) ( struct devlink * devlink , unsigned int port_index ,
struct netlink_ext_ack * extack ) ;
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 09:12:15 +03:00
/**
* port_fn_state_get ( ) - Get the state of a port function
* @ devlink : Devlink instance
* @ port : The devlink port
* @ state : Admin configured state
* @ opstate : Current operational state
* @ extack : extack for reporting error messages
*
* Reports the admin and operational state of a devlink port function
*
* Return : 0 on success , negative value otherwise .
*/
2021-08-08 14:41:21 +03:00
int ( * port_fn_state_get ) ( struct devlink_port * port ,
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 09:12:15 +03:00
enum devlink_port_fn_state * state ,
enum devlink_port_fn_opstate * opstate ,
struct netlink_ext_ack * extack ) ;
/**
* port_fn_state_set ( ) - Set the admin state of a port function
* @ devlink : Devlink instance
* @ port : The devlink port
* @ state : Admin state
* @ extack : extack for reporting error messages
*
* Set the admin state of a devlink port function
*
* Return : 0 on success , negative value otherwise .
*/
2021-08-08 14:41:21 +03:00
int ( * port_fn_state_set ) ( struct devlink_port * port ,
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 09:12:15 +03:00
enum devlink_port_fn_state state ,
struct netlink_ext_ack * extack ) ;
2021-06-02 15:17:22 +03:00
/**
* Rate control callbacks .
*/
int ( * rate_leaf_tx_share_set ) ( struct devlink_rate * devlink_rate , void * priv ,
u64 tx_share , struct netlink_ext_ack * extack ) ;
int ( * rate_leaf_tx_max_set ) ( struct devlink_rate * devlink_rate , void * priv ,
u64 tx_max , struct netlink_ext_ack * extack ) ;
2021-06-02 15:17:25 +03:00
int ( * rate_node_tx_share_set ) ( struct devlink_rate * devlink_rate , void * priv ,
u64 tx_share , struct netlink_ext_ack * extack ) ;
int ( * rate_node_tx_max_set ) ( struct devlink_rate * devlink_rate , void * priv ,
u64 tx_max , struct netlink_ext_ack * extack ) ;
int ( * rate_node_new ) ( struct devlink_rate * rate_node , void * * priv ,
struct netlink_ext_ack * extack ) ;
int ( * rate_node_del ) ( struct devlink_rate * rate_node , void * priv ,
struct netlink_ext_ack * extack ) ;
2021-06-02 15:17:28 +03:00
int ( * rate_leaf_parent_set ) ( struct devlink_rate * child ,
struct devlink_rate * parent ,
void * priv_child , void * priv_parent ,
struct netlink_ext_ack * extack ) ;
int ( * rate_node_parent_set ) ( struct devlink_rate * child ,
struct devlink_rate * parent ,
void * priv_child , void * priv_parent ,
struct netlink_ext_ack * extack ) ;
2016-02-26 19:32:23 +03:00
} ;
2021-10-12 16:15:21 +03:00
void * devlink_priv ( struct devlink * devlink ) ;
struct devlink * priv_to_devlink ( void * priv ) ;
struct device * devlink_to_dev ( const struct devlink * devlink ) ;
2016-02-26 19:32:23 +03:00
2022-03-15 09:00:04 +03:00
/* Devlink instance explicit locking */
void devl_lock ( struct devlink * devlink ) ;
void devl_unlock ( struct devlink * devlink ) ;
void devl_assert_locked ( struct devlink * devlink ) ;
bool devl_lock_is_held ( struct devlink * devlink ) ;
2016-02-26 19:32:23 +03:00
struct ib_device ;
2019-10-03 12:49:31 +03:00
struct net * devlink_net ( const struct devlink * devlink ) ;
2021-07-29 20:19:25 +03:00
/* This call is intended for software devices that can create
* devlink instances in other namespaces than init_net .
*
* Drivers that operate on real HW must use devlink_alloc ( ) instead .
*/
struct devlink * devlink_alloc_ns ( const struct devlink_ops * ops ,
2021-08-08 21:57:43 +03:00
size_t priv_size , struct net * net ,
struct device * dev ) ;
2021-07-29 20:19:25 +03:00
static inline struct devlink * devlink_alloc ( const struct devlink_ops * ops ,
2021-08-08 21:57:43 +03:00
size_t priv_size ,
struct device * dev )
2021-07-29 20:19:25 +03:00
{
2021-08-08 21:57:43 +03:00
return devlink_alloc_ns ( ops , priv_size , & init_net , dev ) ;
2021-07-29 20:19:25 +03:00
}
2021-10-12 16:15:24 +03:00
void devlink_set_features ( struct devlink * devlink , u64 features ) ;
2021-09-22 11:58:03 +03:00
void devlink_register ( struct devlink * devlink ) ;
2016-02-26 19:32:23 +03:00
void devlink_unregister ( struct devlink * devlink ) ;
void devlink_free ( struct devlink * devlink ) ;
2022-07-12 13:24:24 +03:00
int devl_port_register ( struct devlink * devlink ,
struct devlink_port * devlink_port ,
unsigned int port_index ) ;
2016-02-26 19:32:23 +03:00
int devlink_port_register ( struct devlink * devlink ,
struct devlink_port * devlink_port ,
unsigned int port_index ) ;
2022-07-12 13:24:24 +03:00
void devl_port_unregister ( struct devlink_port * devlink_port ) ;
2016-02-26 19:32:23 +03:00
void devlink_port_unregister ( struct devlink_port * devlink_port ) ;
void devlink_port_type_eth_set ( struct devlink_port * devlink_port ,
struct net_device * netdev ) ;
void devlink_port_type_ib_set ( struct devlink_port * devlink_port ,
struct ib_device * ibdev ) ;
void devlink_port_type_clear ( struct devlink_port * devlink_port ) ;
2018-05-18 10:29:00 +03:00
void devlink_port_attrs_set ( struct devlink_port * devlink_port ,
2020-07-09 16:18:16 +03:00
struct devlink_port_attrs * devlink_port_attrs ) ;
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 07:50:37 +03:00
void devlink_port_attrs_pci_pf_set ( struct devlink_port * devlink_port , u32 controller ,
u16 pf , bool external ) ;
void devlink_port_attrs_pci_vf_set ( struct devlink_port * devlink_port , u32 controller ,
2020-09-09 07:50:36 +03:00
u16 pf , u16 vf , bool external ) ;
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 09:12:13 +03:00
void devlink_port_attrs_pci_sf_set ( struct devlink_port * devlink_port ,
2021-03-10 16:35:03 +03:00
u32 controller , u16 pf , u32 sf ,
bool external ) ;
2022-07-12 13:24:24 +03:00
int devl_rate_leaf_create ( struct devlink_port * port , void * priv ) ;
void devl_rate_leaf_destroy ( struct devlink_port * devlink_port ) ;
void devl_rate_nodes_destroy ( struct devlink * devlink ) ;
2022-04-18 09:42:28 +03:00
void devlink_port_linecard_set ( struct devlink_port * devlink_port ,
struct devlink_linecard * linecard ) ;
2022-04-18 09:42:26 +03:00
struct devlink_linecard *
devlink_linecard_create ( struct devlink * devlink , unsigned int linecard_index ,
const struct devlink_linecard_ops * ops , void * priv ) ;
2022-04-18 09:42:25 +03:00
void devlink_linecard_destroy ( struct devlink_linecard * linecard ) ;
2022-04-18 09:42:26 +03:00
void devlink_linecard_provision_set ( struct devlink_linecard * linecard ,
const char * type ) ;
void devlink_linecard_provision_clear ( struct devlink_linecard * linecard ) ;
void devlink_linecard_provision_fail ( struct devlink_linecard * linecard ) ;
2022-04-18 09:42:27 +03:00
void devlink_linecard_activate ( struct devlink_linecard * linecard ) ;
void devlink_linecard_deactivate ( struct devlink_linecard * linecard ) ;
2022-07-16 14:02:36 +03:00
int devl_sb_register ( struct devlink * devlink , unsigned int sb_index ,
u32 size , u16 ingress_pools_count ,
u16 egress_pools_count , u16 ingress_tc_count ,
u16 egress_tc_count ) ;
2016-04-14 19:19:13 +03:00
int devlink_sb_register ( struct devlink * devlink , unsigned int sb_index ,
u32 size , u16 ingress_pools_count ,
u16 egress_pools_count , u16 ingress_tc_count ,
u16 egress_tc_count ) ;
2022-07-16 14:02:36 +03:00
void devl_sb_unregister ( struct devlink * devlink , unsigned int sb_index ) ;
2016-04-14 19:19:13 +03:00
void devlink_sb_unregister ( struct devlink * devlink , unsigned int sb_index ) ;
2022-07-16 14:02:37 +03:00
int devl_dpipe_table_register ( struct devlink * devlink ,
const char * table_name ,
struct devlink_dpipe_table_ops * table_ops ,
void * priv , bool counter_control_extern ) ;
2017-03-28 18:24:10 +03:00
int devlink_dpipe_table_register ( struct devlink * devlink ,
const char * table_name ,
struct devlink_dpipe_table_ops * table_ops ,
2017-08-24 09:40:02 +03:00
void * priv , bool counter_control_extern ) ;
2022-07-16 14:02:37 +03:00
void devl_dpipe_table_unregister ( struct devlink * devlink ,
const char * table_name ) ;
2017-03-28 18:24:10 +03:00
void devlink_dpipe_table_unregister ( struct devlink * devlink ,
const char * table_name ) ;
2022-07-16 14:02:37 +03:00
void devl_dpipe_headers_register ( struct devlink * devlink ,
struct devlink_dpipe_headers * dpipe_headers ) ;
2022-07-13 17:18:51 +03:00
void devlink_dpipe_headers_register ( struct devlink * devlink ,
2017-03-28 18:24:10 +03:00
struct devlink_dpipe_headers * dpipe_headers ) ;
2022-07-16 14:02:37 +03:00
void devl_dpipe_headers_unregister ( struct devlink * devlink ) ;
2017-03-28 18:24:10 +03:00
void devlink_dpipe_headers_unregister ( struct devlink * devlink ) ;
bool devlink_dpipe_table_counter_enabled ( struct devlink * devlink ,
const char * table_name ) ;
int devlink_dpipe_entry_ctx_prepare ( struct devlink_dpipe_dump_ctx * dump_ctx ) ;
int devlink_dpipe_entry_ctx_append ( struct devlink_dpipe_dump_ctx * dump_ctx ,
struct devlink_dpipe_entry * entry ) ;
int devlink_dpipe_entry_ctx_close ( struct devlink_dpipe_dump_ctx * dump_ctx ) ;
2017-08-24 09:40:03 +03:00
void devlink_dpipe_entry_clear ( struct devlink_dpipe_entry * entry ) ;
2017-03-28 18:24:10 +03:00
int devlink_dpipe_action_put ( struct sk_buff * skb ,
struct devlink_dpipe_action * action ) ;
int devlink_dpipe_match_put ( struct sk_buff * skb ,
struct devlink_dpipe_match * match ) ;
2017-08-24 09:39:59 +03:00
extern struct devlink_dpipe_header devlink_dpipe_header_ethernet ;
2017-08-24 09:40:00 +03:00
extern struct devlink_dpipe_header devlink_dpipe_header_ipv4 ;
2017-08-31 18:59:12 +03:00
extern struct devlink_dpipe_header devlink_dpipe_header_ipv6 ;
2016-02-26 19:32:23 +03:00
2022-07-16 14:02:35 +03:00
int devl_resource_register ( struct devlink * devlink ,
const char * resource_name ,
u64 resource_size ,
u64 resource_id ,
u64 parent_resource_id ,
const struct devlink_resource_size_params * size_params ) ;
2018-01-15 10:59:03 +03:00
int devlink_resource_register ( struct devlink * devlink ,
const char * resource_name ,
u64 resource_size ,
u64 resource_id ,
u64 parent_resource_id ,
2018-04-05 23:13:21 +03:00
const struct devlink_resource_size_params * size_params ) ;
2022-07-16 14:02:35 +03:00
void devl_resources_unregister ( struct devlink * devlink ) ;
2021-11-30 13:16:20 +03:00
void devlink_resources_unregister ( struct devlink * devlink ) ;
2022-07-16 14:02:35 +03:00
int devl_resource_size_get ( struct devlink * devlink ,
u64 resource_id ,
u64 * p_resource_size ) ;
2018-01-15 10:59:03 +03:00
int devlink_resource_size_get ( struct devlink * devlink ,
u64 resource_id ,
u64 * p_resource_size ) ;
2022-07-16 14:02:37 +03:00
int devl_dpipe_table_resource_set ( struct devlink * devlink ,
const char * table_name , u64 resource_id ,
u64 resource_units ) ;
2018-01-15 10:59:05 +03:00
int devlink_dpipe_table_resource_set ( struct devlink * devlink ,
const char * table_name , u64 resource_id ,
u64 resource_units ) ;
2022-07-16 14:02:35 +03:00
void devl_resource_occ_get_register ( struct devlink * devlink ,
u64 resource_id ,
devlink_resource_occ_get_t * occ_get ,
void * occ_get_priv ) ;
2018-04-05 23:13:21 +03:00
void devlink_resource_occ_get_register ( struct devlink * devlink ,
u64 resource_id ,
devlink_resource_occ_get_t * occ_get ,
void * occ_get_priv ) ;
2022-07-16 14:02:35 +03:00
void devl_resource_occ_get_unregister ( struct devlink * devlink ,
u64 resource_id ) ;
2018-04-05 23:13:21 +03:00
void devlink_resource_occ_get_unregister ( struct devlink * devlink ,
u64 resource_id ) ;
2018-07-04 14:30:28 +03:00
int devlink_params_register ( struct devlink * devlink ,
const struct devlink_param * params ,
size_t params_count ) ;
void devlink_params_unregister ( struct devlink * devlink ,
const struct devlink_param * params ,
size_t params_count ) ;
2021-08-10 16:24:19 +03:00
int devlink_param_register ( struct devlink * devlink ,
const struct devlink_param * param ) ;
void devlink_param_unregister ( struct devlink * devlink ,
const struct devlink_param * param ) ;
2018-07-04 14:30:31 +03:00
int devlink_param_driverinit_value_get ( struct devlink * devlink , u32 param_id ,
union devlink_param_value * init_val ) ;
int devlink_param_driverinit_value_set ( struct devlink * devlink , u32 param_id ,
union devlink_param_value init_val ) ;
2018-07-04 14:30:32 +03:00
void devlink_param_value_changed ( struct devlink * devlink , u32 param_id ) ;
2022-07-16 14:02:39 +03:00
struct devlink_region * devl_region_create ( struct devlink * devlink ,
const struct devlink_region_ops * ops ,
u32 region_max_snapshots ,
u64 region_size ) ;
2020-03-26 21:37:08 +03:00
struct devlink_region *
devlink_region_create ( struct devlink * devlink ,
const struct devlink_region_ops * ops ,
u32 region_max_snapshots , u64 region_size ) ;
2020-10-04 19:12:54 +03:00
struct devlink_region *
devlink_port_region_create ( struct devlink_port * port ,
const struct devlink_port_region_ops * ops ,
u32 region_max_snapshots , u64 region_size ) ;
2022-07-16 14:02:39 +03:00
void devl_region_destroy ( struct devlink_region * region ) ;
2018-07-12 15:13:08 +03:00
void devlink_region_destroy ( struct devlink_region * region ) ;
2020-10-04 19:12:54 +03:00
void devlink_port_region_destroy ( struct devlink_region * region ) ;
2020-03-26 21:37:14 +03:00
int devlink_region_snapshot_id_get ( struct devlink * devlink , u32 * id ) ;
2020-03-26 21:37:15 +03:00
void devlink_region_snapshot_id_put ( struct devlink * devlink , u32 id ) ;
2019-08-09 16:27:15 +03:00
int devlink_region_snapshot_create ( struct devlink_region * region ,
2020-03-26 21:37:09 +03:00
u8 * data , u32 snapshot_id ) ;
2019-01-31 21:50:40 +03:00
int devlink_info_serial_number_put ( struct devlink_info_req * req ,
const char * sn ) ;
int devlink_info_driver_name_put ( struct devlink_info_req * req ,
const char * name ) ;
2020-06-20 19:31:56 +03:00
int devlink_info_board_serial_number_put ( struct devlink_info_req * req ,
const char * bsn ) ;
2019-01-31 21:50:41 +03:00
int devlink_info_version_fixed_put ( struct devlink_info_req * req ,
const char * version_name ,
const char * version_value ) ;
int devlink_info_version_stored_put ( struct devlink_info_req * req ,
const char * version_name ,
const char * version_value ) ;
int devlink_info_version_running_put ( struct devlink_info_req * req ,
const char * version_name ,
const char * version_value ) ;
2018-01-15 10:59:03 +03:00
2019-02-07 12:36:32 +03:00
int devlink_fmsg_obj_nest_start ( struct devlink_fmsg * fmsg ) ;
int devlink_fmsg_obj_nest_end ( struct devlink_fmsg * fmsg ) ;
int devlink_fmsg_pair_nest_start ( struct devlink_fmsg * fmsg , const char * name ) ;
int devlink_fmsg_pair_nest_end ( struct devlink_fmsg * fmsg ) ;
int devlink_fmsg_arr_pair_nest_start ( struct devlink_fmsg * fmsg ,
const char * name ) ;
int devlink_fmsg_arr_pair_nest_end ( struct devlink_fmsg * fmsg ) ;
2020-02-12 01:32:42 +03:00
int devlink_fmsg_binary_pair_nest_start ( struct devlink_fmsg * fmsg ,
const char * name ) ;
int devlink_fmsg_binary_pair_nest_end ( struct devlink_fmsg * fmsg ) ;
2019-02-07 12:36:32 +03:00
int devlink_fmsg_u32_put ( struct devlink_fmsg * fmsg , u32 value ) ;
int devlink_fmsg_string_put ( struct devlink_fmsg * fmsg , const char * value ) ;
2020-02-12 01:32:42 +03:00
int devlink_fmsg_binary_put ( struct devlink_fmsg * fmsg , const void * value ,
u16 value_len ) ;
2019-02-07 12:36:32 +03:00
int devlink_fmsg_bool_pair_put ( struct devlink_fmsg * fmsg , const char * name ,
bool value ) ;
int devlink_fmsg_u8_pair_put ( struct devlink_fmsg * fmsg , const char * name ,
u8 value ) ;
int devlink_fmsg_u32_pair_put ( struct devlink_fmsg * fmsg , const char * name ,
u32 value ) ;
int devlink_fmsg_u64_pair_put ( struct devlink_fmsg * fmsg , const char * name ,
u64 value ) ;
int devlink_fmsg_string_pair_put ( struct devlink_fmsg * fmsg , const char * name ,
const char * value ) ;
int devlink_fmsg_binary_pair_put ( struct devlink_fmsg * fmsg , const char * name ,
2019-11-12 15:07:49 +03:00
const void * value , u32 value_len ) ;
2019-02-07 12:36:32 +03:00
2019-02-07 12:36:33 +03:00
struct devlink_health_reporter *
devlink_health_reporter_create ( struct devlink * devlink ,
const struct devlink_health_reporter_ops * ops ,
2020-03-29 14:05:54 +03:00
u64 graceful_period , void * priv ) ;
2020-07-10 15:25:11 +03:00
struct devlink_health_reporter *
devlink_port_health_reporter_create ( struct devlink_port * port ,
const struct devlink_health_reporter_ops * ops ,
u64 graceful_period , void * priv ) ;
2019-02-07 12:36:33 +03:00
void
devlink_health_reporter_destroy ( struct devlink_health_reporter * reporter ) ;
2020-07-10 15:25:11 +03:00
void
devlink_port_health_reporter_destroy ( struct devlink_health_reporter * reporter ) ;
2019-02-07 12:36:33 +03:00
void *
devlink_health_reporter_priv ( struct devlink_health_reporter * reporter ) ;
2019-02-07 12:36:34 +03:00
int devlink_health_report ( struct devlink_health_reporter * reporter ,
const char * msg , void * priv_ctx ) ;
2019-03-03 11:57:30 +03:00
void
devlink_health_reporter_state_update ( struct devlink_health_reporter * reporter ,
enum devlink_health_reporter_state state ) ;
2020-01-02 18:48:09 +03:00
void
devlink_health_reporter_recovery_done ( struct devlink_health_reporter * reporter ) ;
2019-02-07 12:36:33 +03:00
2019-09-12 11:49:46 +03:00
bool devlink_is_reload_failed ( const struct devlink * devlink ) ;
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 09:00:46 +03:00
void devlink_remote_reload_actions_performed ( struct devlink * devlink ,
enum devlink_reload_limit limit ,
u32 actions_performed ) ;
2019-09-12 11:49:46 +03:00
2019-06-04 16:40:40 +03:00
void devlink_flash_update_status_notify ( struct devlink * devlink ,
const char * status_msg ,
const char * component ,
unsigned long done ,
unsigned long total ) ;
2020-09-18 04:13:23 +03:00
void devlink_flash_update_timeout_notify ( struct devlink * devlink ,
const char * status_msg ,
const char * component ,
unsigned long timeout ) ;
2019-06-04 16:40:40 +03:00
2022-07-16 14:02:34 +03:00
int devl_traps_register ( struct devlink * devlink ,
const struct devlink_trap * traps ,
size_t traps_count , void * priv ) ;
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 16:28:17 +03:00
int devlink_traps_register ( struct devlink * devlink ,
const struct devlink_trap * traps ,
size_t traps_count , void * priv ) ;
2022-07-16 14:02:34 +03:00
void devl_traps_unregister ( struct devlink * devlink ,
const struct devlink_trap * traps ,
size_t traps_count ) ;
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 16:28:17 +03:00
void devlink_traps_unregister ( struct devlink * devlink ,
const struct devlink_trap * traps ,
size_t traps_count ) ;
2020-02-25 13:45:21 +03:00
void devlink_trap_report ( struct devlink * devlink , struct sk_buff * skb ,
void * trap_ctx , struct devlink_port * in_devlink_port ,
const struct flow_action_cookie * 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 16:28:17 +03:00
void * devlink_trap_ctx_priv ( void * trap_ctx ) ;
2022-07-16 14:02:34 +03:00
int devl_trap_groups_register ( struct devlink * devlink ,
const struct devlink_trap_group * groups ,
size_t groups_count ) ;
2020-03-22 21:48:26 +03:00
int devlink_trap_groups_register ( struct devlink * devlink ,
const struct devlink_trap_group * groups ,
size_t groups_count ) ;
2022-07-16 14:02:34 +03:00
void devl_trap_groups_unregister ( struct devlink * devlink ,
const struct devlink_trap_group * groups ,
size_t groups_count ) ;
2020-03-22 21:48:26 +03:00
void devlink_trap_groups_unregister ( struct devlink * devlink ,
const struct devlink_trap_group * groups ,
size_t groups_count ) ;
2020-03-30 22:38:18 +03:00
int
2022-07-16 14:02:34 +03:00
devl_trap_policers_register ( struct devlink * devlink ,
const struct devlink_trap_policer * policers ,
size_t policers_count ) ;
int
2020-03-30 22:38:18 +03:00
devlink_trap_policers_register ( struct devlink * devlink ,
const struct devlink_trap_policer * policers ,
size_t policers_count ) ;
void
2022-07-16 14:02:34 +03:00
devl_trap_policers_unregister ( struct devlink * devlink ,
const struct devlink_trap_policer * policers ,
size_t policers_count ) ;
void
2020-03-30 22:38:18 +03:00
devlink_trap_policers_unregister ( struct devlink * devlink ,
const struct devlink_trap_policer * policers ,
size_t policers_count ) ;
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 16:28:17 +03:00
2019-03-24 13:14:38 +03:00
# if IS_ENABLED(CONFIG_NET_DEVLINK)
2021-10-30 20:18:50 +03:00
struct devlink * __must_check devlink_try_get ( struct devlink * devlink ) ;
void devlink_put ( struct devlink * devlink ) ;
2021-10-30 20:18:51 +03:00
void devlink_compat_running_version ( struct devlink * devlink ,
2019-02-26 06:34:02 +03:00
char * buf , size_t len ) ;
2021-10-30 20:18:51 +03:00
int devlink_compat_flash_update ( struct devlink * devlink , const char * file_name ) ;
2019-03-28 15:56:37 +03:00
int devlink_compat_phys_port_name_get ( struct net_device * dev ,
char * name , size_t len ) ;
2019-04-03 15:24:17 +03:00
int devlink_compat_switch_id_get ( struct net_device * dev ,
struct netdev_phys_item_id * ppid ) ;
2019-02-26 06:34:02 +03:00
2016-02-26 19:32:23 +03:00
# else
2021-10-30 20:18:50 +03:00
static inline struct devlink * devlink_try_get ( struct devlink * devlink )
{
return NULL ;
}
static inline void devlink_put ( struct devlink * devlink )
{
}
2019-01-31 21:50:47 +03:00
static inline void
2021-10-30 20:18:51 +03:00
devlink_compat_running_version ( struct devlink * devlink , char * buf , size_t len )
2019-01-31 21:50:47 +03:00
{
}
2019-02-15 00:40:45 +03:00
static inline int
2021-10-30 20:18:51 +03:00
devlink_compat_flash_update ( struct devlink * devlink , const char * file_name )
2019-02-15 00:40:45 +03:00
{
return - EOPNOTSUPP ;
}
2019-03-24 13:14:38 +03:00
2019-03-28 15:56:37 +03:00
static inline int
devlink_compat_phys_port_name_get ( struct net_device * dev ,
char * name , size_t len )
{
return - EOPNOTSUPP ;
}
2019-04-03 15:24:17 +03:00
static inline int
devlink_compat_switch_id_get ( struct net_device * dev ,
struct netdev_phys_item_id * ppid )
{
return - EOPNOTSUPP ;
}
2019-01-31 21:50:47 +03:00
# endif
2016-02-26 19:32:23 +03:00
# endif /* _NET_DEVLINK_H_ */