2017-11-01 17:08:43 +03:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
|
2012-10-13 13:46:48 +04:00
|
|
|
#ifndef _UAPI_LINUX_IF_LINK_H
|
|
|
|
#define _UAPI_LINUX_IF_LINK_H
|
|
|
|
|
|
|
|
#include <linux/types.h>
|
|
|
|
#include <linux/netlink.h>
|
|
|
|
|
|
|
|
/* This struct should be in sync with struct rtnl_link_stats64 */
|
|
|
|
struct rtnl_link_stats {
|
2020-09-17 20:51:32 +03:00
|
|
|
__u32 rx_packets;
|
|
|
|
__u32 tx_packets;
|
|
|
|
__u32 rx_bytes;
|
|
|
|
__u32 tx_bytes;
|
|
|
|
__u32 rx_errors;
|
|
|
|
__u32 tx_errors;
|
|
|
|
__u32 rx_dropped;
|
|
|
|
__u32 tx_dropped;
|
|
|
|
__u32 multicast;
|
2012-10-13 13:46:48 +04:00
|
|
|
__u32 collisions;
|
|
|
|
/* detailed rx_errors: */
|
|
|
|
__u32 rx_length_errors;
|
2020-09-17 20:51:32 +03:00
|
|
|
__u32 rx_over_errors;
|
|
|
|
__u32 rx_crc_errors;
|
|
|
|
__u32 rx_frame_errors;
|
|
|
|
__u32 rx_fifo_errors;
|
|
|
|
__u32 rx_missed_errors;
|
2012-10-13 13:46:48 +04:00
|
|
|
|
|
|
|
/* detailed tx_errors */
|
|
|
|
__u32 tx_aborted_errors;
|
|
|
|
__u32 tx_carrier_errors;
|
|
|
|
__u32 tx_fifo_errors;
|
|
|
|
__u32 tx_heartbeat_errors;
|
|
|
|
__u32 tx_window_errors;
|
|
|
|
|
|
|
|
/* for cslip etc */
|
|
|
|
__u32 rx_compressed;
|
|
|
|
__u32 tx_compressed;
|
2016-02-02 02:51:05 +03:00
|
|
|
|
2020-09-17 20:51:32 +03:00
|
|
|
__u32 rx_nohandler;
|
2012-10-13 13:46:48 +04:00
|
|
|
};
|
|
|
|
|
net: tighten the definition of interface statistics
This patch is born out of an investigation into which IEEE statistics
correspond to which struct rtnl_link_stats64 members. Turns out that
there seems to be reasonable consensus on the matter, among many drivers.
To save others the time (and it took more time than I'm comfortable
admitting) I'm adding comments referring to IEEE attributes to
struct rtnl_link_stats64.
Up until now we had two forms of documentation for stats - in
Documentation/ABI/testing/sysfs-class-net-statistics and the comments
on struct rtnl_link_stats64 itself. While the former is very cautious
in defining the expected behavior, the latter feel quite dated and
may not be easy to understand for modern day driver author
(e.g. rx_over_errors). At the same time modern systems are far more
complex and once obvious definitions lost their clarity. For example
- does rx_packet count at the MAC layer (aFramesReceivedOK)?
packets processed correctly by hardware? received by the driver?
or maybe received by the stack?
I tried to clarify the expectations, further clarifications from
others are very welcome.
The part hardest to untangle is rx_over_errors vs rx_fifo_errors
vs rx_missed_errors. After much deliberation I concluded that for
modern HW only two of the counters will make sense. The distinction
between internal FIFO overflow and packets dropped due to back-pressure
from the host is likely too implementation (driver and device) specific
to expose in the standard stats.
Now - which two of those counters we select to use is anyone's pick:
sysfs documentation suggests rx_over_errors counts packets which
did not fit into buffers due to MTU being too small, which I reused.
There don't seem to be many modern drivers using it (well, CAN drivers
seem to love this statistic).
Of the remaining two I picked rx_missed_errors to report device drops.
bnxt reports it and it's folded into "drop"s in procfs (while
rx_fifo_errors is an error, and modern devices usually receive the frame
OK, they just can't admit it into the pipeline).
Of the drivers I looked at only AMD Lance-like and NS8390-like use all
three of these counters. rx_missed_errors counts missed frames,
rx_over_errors counts overflow events, and rx_fifo_errors counts frames
which were truncated because they didn't fit into buffers. This suggests
that rx_fifo_errors may be the correct stat for truncated packets, but
I'd think a FIFO stat counting truncated packets would be very confusing
to a modern reader.
v2:
- add driver developer notes about ethtool stat count and reset
- replace Ethernet with IEEE 802.3 to better indicate source of attrs
- mention byte counters don't count FCS
- clarify RX counter is from device to host
- drop "sightly" from sysfs paragraph
- add examples of ethtool stats
- s/incoming/received/ s/incoming/transmitted/
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-09-04 02:14:31 +03:00
|
|
|
/**
|
|
|
|
* struct rtnl_link_stats64 - The main device statistics structure.
|
|
|
|
*
|
|
|
|
* @rx_packets: Number of good packets received by the interface.
|
|
|
|
* For hardware interfaces counts all good packets received from the device
|
|
|
|
* by the host, including packets which host had to drop at various stages
|
|
|
|
* of processing (even in the driver).
|
|
|
|
*
|
|
|
|
* @tx_packets: Number of packets successfully transmitted.
|
|
|
|
* For hardware interfaces counts packets which host was able to successfully
|
|
|
|
* hand over to the device, which does not necessarily mean that packets
|
|
|
|
* had been successfully transmitted out of the device, only that device
|
|
|
|
* acknowledged it copied them out of host memory.
|
|
|
|
*
|
|
|
|
* @rx_bytes: Number of good received bytes, corresponding to @rx_packets.
|
|
|
|
*
|
|
|
|
* For IEEE 802.3 devices should count the length of Ethernet Frames
|
|
|
|
* excluding the FCS.
|
|
|
|
*
|
|
|
|
* @tx_bytes: Number of good transmitted bytes, corresponding to @tx_packets.
|
|
|
|
*
|
|
|
|
* For IEEE 802.3 devices should count the length of Ethernet Frames
|
|
|
|
* excluding the FCS.
|
|
|
|
*
|
|
|
|
* @rx_errors: Total number of bad packets received on this network device.
|
|
|
|
* This counter must include events counted by @rx_length_errors,
|
|
|
|
* @rx_crc_errors, @rx_frame_errors and other errors not otherwise
|
|
|
|
* counted.
|
|
|
|
*
|
|
|
|
* @tx_errors: Total number of transmit problems.
|
|
|
|
* This counter must include events counter by @tx_aborted_errors,
|
|
|
|
* @tx_carrier_errors, @tx_fifo_errors, @tx_heartbeat_errors,
|
|
|
|
* @tx_window_errors and other errors not otherwise counted.
|
|
|
|
*
|
|
|
|
* @rx_dropped: Number of packets received but not processed,
|
|
|
|
* e.g. due to lack of resources or unsupported protocol.
|
2020-12-31 06:37:53 +03:00
|
|
|
* For hardware interfaces this counter may include packets discarded
|
|
|
|
* due to L2 address filtering but should not include packets dropped
|
|
|
|
* by the device due to buffer exhaustion which are counted separately in
|
net: tighten the definition of interface statistics
This patch is born out of an investigation into which IEEE statistics
correspond to which struct rtnl_link_stats64 members. Turns out that
there seems to be reasonable consensus on the matter, among many drivers.
To save others the time (and it took more time than I'm comfortable
admitting) I'm adding comments referring to IEEE attributes to
struct rtnl_link_stats64.
Up until now we had two forms of documentation for stats - in
Documentation/ABI/testing/sysfs-class-net-statistics and the comments
on struct rtnl_link_stats64 itself. While the former is very cautious
in defining the expected behavior, the latter feel quite dated and
may not be easy to understand for modern day driver author
(e.g. rx_over_errors). At the same time modern systems are far more
complex and once obvious definitions lost their clarity. For example
- does rx_packet count at the MAC layer (aFramesReceivedOK)?
packets processed correctly by hardware? received by the driver?
or maybe received by the stack?
I tried to clarify the expectations, further clarifications from
others are very welcome.
The part hardest to untangle is rx_over_errors vs rx_fifo_errors
vs rx_missed_errors. After much deliberation I concluded that for
modern HW only two of the counters will make sense. The distinction
between internal FIFO overflow and packets dropped due to back-pressure
from the host is likely too implementation (driver and device) specific
to expose in the standard stats.
Now - which two of those counters we select to use is anyone's pick:
sysfs documentation suggests rx_over_errors counts packets which
did not fit into buffers due to MTU being too small, which I reused.
There don't seem to be many modern drivers using it (well, CAN drivers
seem to love this statistic).
Of the remaining two I picked rx_missed_errors to report device drops.
bnxt reports it and it's folded into "drop"s in procfs (while
rx_fifo_errors is an error, and modern devices usually receive the frame
OK, they just can't admit it into the pipeline).
Of the drivers I looked at only AMD Lance-like and NS8390-like use all
three of these counters. rx_missed_errors counts missed frames,
rx_over_errors counts overflow events, and rx_fifo_errors counts frames
which were truncated because they didn't fit into buffers. This suggests
that rx_fifo_errors may be the correct stat for truncated packets, but
I'd think a FIFO stat counting truncated packets would be very confusing
to a modern reader.
v2:
- add driver developer notes about ethtool stat count and reset
- replace Ethernet with IEEE 802.3 to better indicate source of attrs
- mention byte counters don't count FCS
- clarify RX counter is from device to host
- drop "sightly" from sysfs paragraph
- add examples of ethtool stats
- s/incoming/received/ s/incoming/transmitted/
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-09-04 02:14:31 +03:00
|
|
|
* @rx_missed_errors (since procfs folds those two counters together).
|
|
|
|
*
|
|
|
|
* @tx_dropped: Number of packets dropped on their way to transmission,
|
|
|
|
* e.g. due to lack of resources.
|
|
|
|
*
|
|
|
|
* @multicast: Multicast packets received.
|
|
|
|
* For hardware interfaces this statistic is commonly calculated
|
|
|
|
* at the device level (unlike @rx_packets) and therefore may include
|
|
|
|
* packets which did not reach the host.
|
|
|
|
*
|
|
|
|
* For IEEE 802.3 devices this counter may be equivalent to:
|
|
|
|
*
|
|
|
|
* - 30.3.1.1.21 aMulticastFramesReceivedOK
|
|
|
|
*
|
|
|
|
* @collisions: Number of collisions during packet transmissions.
|
|
|
|
*
|
|
|
|
* @rx_length_errors: Number of packets dropped due to invalid length.
|
|
|
|
* Part of aggregate "frame" errors in `/proc/net/dev`.
|
|
|
|
*
|
|
|
|
* For IEEE 802.3 devices this counter should be equivalent to a sum
|
|
|
|
* of the following attributes:
|
|
|
|
*
|
|
|
|
* - 30.3.1.1.23 aInRangeLengthErrors
|
|
|
|
* - 30.3.1.1.24 aOutOfRangeLengthField
|
|
|
|
* - 30.3.1.1.25 aFrameTooLongErrors
|
|
|
|
*
|
|
|
|
* @rx_over_errors: Receiver FIFO overflow event counter.
|
|
|
|
*
|
|
|
|
* Historically the count of overflow events. Such events may be
|
|
|
|
* reported in the receive descriptors or via interrupts, and may
|
|
|
|
* not correspond one-to-one with dropped packets.
|
|
|
|
*
|
|
|
|
* The recommended interpretation for high speed interfaces is -
|
|
|
|
* number of packets dropped because they did not fit into buffers
|
|
|
|
* provided by the host, e.g. packets larger than MTU or next buffer
|
|
|
|
* in the ring was not available for a scatter transfer.
|
|
|
|
*
|
|
|
|
* Part of aggregate "frame" errors in `/proc/net/dev`.
|
|
|
|
*
|
|
|
|
* This statistics was historically used interchangeably with
|
|
|
|
* @rx_fifo_errors.
|
|
|
|
*
|
|
|
|
* This statistic corresponds to hardware events and is not commonly used
|
|
|
|
* on software devices.
|
|
|
|
*
|
|
|
|
* @rx_crc_errors: Number of packets received with a CRC error.
|
|
|
|
* Part of aggregate "frame" errors in `/proc/net/dev`.
|
|
|
|
*
|
|
|
|
* For IEEE 802.3 devices this counter must be equivalent to:
|
|
|
|
*
|
|
|
|
* - 30.3.1.1.6 aFrameCheckSequenceErrors
|
|
|
|
*
|
|
|
|
* @rx_frame_errors: Receiver frame alignment errors.
|
|
|
|
* Part of aggregate "frame" errors in `/proc/net/dev`.
|
|
|
|
*
|
|
|
|
* For IEEE 802.3 devices this counter should be equivalent to:
|
|
|
|
*
|
|
|
|
* - 30.3.1.1.7 aAlignmentErrors
|
|
|
|
*
|
|
|
|
* @rx_fifo_errors: Receiver FIFO error counter.
|
|
|
|
*
|
|
|
|
* Historically the count of overflow events. Those events may be
|
|
|
|
* reported in the receive descriptors or via interrupts, and may
|
|
|
|
* not correspond one-to-one with dropped packets.
|
|
|
|
*
|
|
|
|
* This statistics was used interchangeably with @rx_over_errors.
|
|
|
|
* Not recommended for use in drivers for high speed interfaces.
|
|
|
|
*
|
|
|
|
* This statistic is used on software devices, e.g. to count software
|
|
|
|
* packet queue overflow (can) or sequencing errors (GRE).
|
|
|
|
*
|
|
|
|
* @rx_missed_errors: Count of packets missed by the host.
|
|
|
|
* Folded into the "drop" counter in `/proc/net/dev`.
|
|
|
|
*
|
|
|
|
* Counts number of packets dropped by the device due to lack
|
|
|
|
* of buffer space. This usually indicates that the host interface
|
|
|
|
* is slower than the network interface, or host is not keeping up
|
|
|
|
* with the receive packet rate.
|
|
|
|
*
|
|
|
|
* This statistic corresponds to hardware events and is not used
|
|
|
|
* on software devices.
|
|
|
|
*
|
|
|
|
* @tx_aborted_errors:
|
|
|
|
* Part of aggregate "carrier" errors in `/proc/net/dev`.
|
|
|
|
* For IEEE 802.3 devices capable of half-duplex operation this counter
|
|
|
|
* must be equivalent to:
|
|
|
|
*
|
|
|
|
* - 30.3.1.1.11 aFramesAbortedDueToXSColls
|
|
|
|
*
|
|
|
|
* High speed interfaces may use this counter as a general device
|
|
|
|
* discard counter.
|
|
|
|
*
|
|
|
|
* @tx_carrier_errors: Number of frame transmission errors due to loss
|
|
|
|
* of carrier during transmission.
|
|
|
|
* Part of aggregate "carrier" errors in `/proc/net/dev`.
|
|
|
|
*
|
|
|
|
* For IEEE 802.3 devices this counter must be equivalent to:
|
|
|
|
*
|
|
|
|
* - 30.3.1.1.13 aCarrierSenseErrors
|
|
|
|
*
|
|
|
|
* @tx_fifo_errors: Number of frame transmission errors due to device
|
|
|
|
* FIFO underrun / underflow. This condition occurs when the device
|
|
|
|
* begins transmission of a frame but is unable to deliver the
|
|
|
|
* entire frame to the transmitter in time for transmission.
|
|
|
|
* Part of aggregate "carrier" errors in `/proc/net/dev`.
|
|
|
|
*
|
|
|
|
* @tx_heartbeat_errors: Number of Heartbeat / SQE Test errors for
|
|
|
|
* old half-duplex Ethernet.
|
|
|
|
* Part of aggregate "carrier" errors in `/proc/net/dev`.
|
|
|
|
*
|
|
|
|
* For IEEE 802.3 devices possibly equivalent to:
|
|
|
|
*
|
|
|
|
* - 30.3.2.1.4 aSQETestErrors
|
|
|
|
*
|
|
|
|
* @tx_window_errors: Number of frame transmission errors due
|
|
|
|
* to late collisions (for Ethernet - after the first 64B of transmission).
|
|
|
|
* Part of aggregate "carrier" errors in `/proc/net/dev`.
|
|
|
|
*
|
|
|
|
* For IEEE 802.3 devices this counter must be equivalent to:
|
|
|
|
*
|
|
|
|
* - 30.3.1.1.10 aLateCollisions
|
|
|
|
*
|
|
|
|
* @rx_compressed: Number of correctly received compressed packets.
|
|
|
|
* This counters is only meaningful for interfaces which support
|
|
|
|
* packet compression (e.g. CSLIP, PPP).
|
|
|
|
*
|
|
|
|
* @tx_compressed: Number of transmitted compressed packets.
|
|
|
|
* This counters is only meaningful for interfaces which support
|
|
|
|
* packet compression (e.g. CSLIP, PPP).
|
|
|
|
*
|
|
|
|
* @rx_nohandler: Number of packets received on the interface
|
|
|
|
* but dropped by the networking stack because the device is
|
|
|
|
* not designated to receive packets (e.g. backup link in a bond).
|
2022-04-06 20:26:00 +03:00
|
|
|
*
|
|
|
|
* @rx_otherhost_dropped: Number of packets dropped due to mismatch
|
|
|
|
* in destination MAC address.
|
net: tighten the definition of interface statistics
This patch is born out of an investigation into which IEEE statistics
correspond to which struct rtnl_link_stats64 members. Turns out that
there seems to be reasonable consensus on the matter, among many drivers.
To save others the time (and it took more time than I'm comfortable
admitting) I'm adding comments referring to IEEE attributes to
struct rtnl_link_stats64.
Up until now we had two forms of documentation for stats - in
Documentation/ABI/testing/sysfs-class-net-statistics and the comments
on struct rtnl_link_stats64 itself. While the former is very cautious
in defining the expected behavior, the latter feel quite dated and
may not be easy to understand for modern day driver author
(e.g. rx_over_errors). At the same time modern systems are far more
complex and once obvious definitions lost their clarity. For example
- does rx_packet count at the MAC layer (aFramesReceivedOK)?
packets processed correctly by hardware? received by the driver?
or maybe received by the stack?
I tried to clarify the expectations, further clarifications from
others are very welcome.
The part hardest to untangle is rx_over_errors vs rx_fifo_errors
vs rx_missed_errors. After much deliberation I concluded that for
modern HW only two of the counters will make sense. The distinction
between internal FIFO overflow and packets dropped due to back-pressure
from the host is likely too implementation (driver and device) specific
to expose in the standard stats.
Now - which two of those counters we select to use is anyone's pick:
sysfs documentation suggests rx_over_errors counts packets which
did not fit into buffers due to MTU being too small, which I reused.
There don't seem to be many modern drivers using it (well, CAN drivers
seem to love this statistic).
Of the remaining two I picked rx_missed_errors to report device drops.
bnxt reports it and it's folded into "drop"s in procfs (while
rx_fifo_errors is an error, and modern devices usually receive the frame
OK, they just can't admit it into the pipeline).
Of the drivers I looked at only AMD Lance-like and NS8390-like use all
three of these counters. rx_missed_errors counts missed frames,
rx_over_errors counts overflow events, and rx_fifo_errors counts frames
which were truncated because they didn't fit into buffers. This suggests
that rx_fifo_errors may be the correct stat for truncated packets, but
I'd think a FIFO stat counting truncated packets would be very confusing
to a modern reader.
v2:
- add driver developer notes about ethtool stat count and reset
- replace Ethernet with IEEE 802.3 to better indicate source of attrs
- mention byte counters don't count FCS
- clarify RX counter is from device to host
- drop "sightly" from sysfs paragraph
- add examples of ethtool stats
- s/incoming/received/ s/incoming/transmitted/
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-09-04 02:14:31 +03:00
|
|
|
*/
|
2012-10-13 13:46:48 +04:00
|
|
|
struct rtnl_link_stats64 {
|
net: tighten the definition of interface statistics
This patch is born out of an investigation into which IEEE statistics
correspond to which struct rtnl_link_stats64 members. Turns out that
there seems to be reasonable consensus on the matter, among many drivers.
To save others the time (and it took more time than I'm comfortable
admitting) I'm adding comments referring to IEEE attributes to
struct rtnl_link_stats64.
Up until now we had two forms of documentation for stats - in
Documentation/ABI/testing/sysfs-class-net-statistics and the comments
on struct rtnl_link_stats64 itself. While the former is very cautious
in defining the expected behavior, the latter feel quite dated and
may not be easy to understand for modern day driver author
(e.g. rx_over_errors). At the same time modern systems are far more
complex and once obvious definitions lost their clarity. For example
- does rx_packet count at the MAC layer (aFramesReceivedOK)?
packets processed correctly by hardware? received by the driver?
or maybe received by the stack?
I tried to clarify the expectations, further clarifications from
others are very welcome.
The part hardest to untangle is rx_over_errors vs rx_fifo_errors
vs rx_missed_errors. After much deliberation I concluded that for
modern HW only two of the counters will make sense. The distinction
between internal FIFO overflow and packets dropped due to back-pressure
from the host is likely too implementation (driver and device) specific
to expose in the standard stats.
Now - which two of those counters we select to use is anyone's pick:
sysfs documentation suggests rx_over_errors counts packets which
did not fit into buffers due to MTU being too small, which I reused.
There don't seem to be many modern drivers using it (well, CAN drivers
seem to love this statistic).
Of the remaining two I picked rx_missed_errors to report device drops.
bnxt reports it and it's folded into "drop"s in procfs (while
rx_fifo_errors is an error, and modern devices usually receive the frame
OK, they just can't admit it into the pipeline).
Of the drivers I looked at only AMD Lance-like and NS8390-like use all
three of these counters. rx_missed_errors counts missed frames,
rx_over_errors counts overflow events, and rx_fifo_errors counts frames
which were truncated because they didn't fit into buffers. This suggests
that rx_fifo_errors may be the correct stat for truncated packets, but
I'd think a FIFO stat counting truncated packets would be very confusing
to a modern reader.
v2:
- add driver developer notes about ethtool stat count and reset
- replace Ethernet with IEEE 802.3 to better indicate source of attrs
- mention byte counters don't count FCS
- clarify RX counter is from device to host
- drop "sightly" from sysfs paragraph
- add examples of ethtool stats
- s/incoming/received/ s/incoming/transmitted/
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-09-04 02:14:31 +03:00
|
|
|
__u64 rx_packets;
|
|
|
|
__u64 tx_packets;
|
|
|
|
__u64 rx_bytes;
|
|
|
|
__u64 tx_bytes;
|
|
|
|
__u64 rx_errors;
|
|
|
|
__u64 tx_errors;
|
|
|
|
__u64 rx_dropped;
|
|
|
|
__u64 tx_dropped;
|
|
|
|
__u64 multicast;
|
2012-10-13 13:46:48 +04:00
|
|
|
__u64 collisions;
|
|
|
|
|
|
|
|
/* detailed rx_errors: */
|
|
|
|
__u64 rx_length_errors;
|
net: tighten the definition of interface statistics
This patch is born out of an investigation into which IEEE statistics
correspond to which struct rtnl_link_stats64 members. Turns out that
there seems to be reasonable consensus on the matter, among many drivers.
To save others the time (and it took more time than I'm comfortable
admitting) I'm adding comments referring to IEEE attributes to
struct rtnl_link_stats64.
Up until now we had two forms of documentation for stats - in
Documentation/ABI/testing/sysfs-class-net-statistics and the comments
on struct rtnl_link_stats64 itself. While the former is very cautious
in defining the expected behavior, the latter feel quite dated and
may not be easy to understand for modern day driver author
(e.g. rx_over_errors). At the same time modern systems are far more
complex and once obvious definitions lost their clarity. For example
- does rx_packet count at the MAC layer (aFramesReceivedOK)?
packets processed correctly by hardware? received by the driver?
or maybe received by the stack?
I tried to clarify the expectations, further clarifications from
others are very welcome.
The part hardest to untangle is rx_over_errors vs rx_fifo_errors
vs rx_missed_errors. After much deliberation I concluded that for
modern HW only two of the counters will make sense. The distinction
between internal FIFO overflow and packets dropped due to back-pressure
from the host is likely too implementation (driver and device) specific
to expose in the standard stats.
Now - which two of those counters we select to use is anyone's pick:
sysfs documentation suggests rx_over_errors counts packets which
did not fit into buffers due to MTU being too small, which I reused.
There don't seem to be many modern drivers using it (well, CAN drivers
seem to love this statistic).
Of the remaining two I picked rx_missed_errors to report device drops.
bnxt reports it and it's folded into "drop"s in procfs (while
rx_fifo_errors is an error, and modern devices usually receive the frame
OK, they just can't admit it into the pipeline).
Of the drivers I looked at only AMD Lance-like and NS8390-like use all
three of these counters. rx_missed_errors counts missed frames,
rx_over_errors counts overflow events, and rx_fifo_errors counts frames
which were truncated because they didn't fit into buffers. This suggests
that rx_fifo_errors may be the correct stat for truncated packets, but
I'd think a FIFO stat counting truncated packets would be very confusing
to a modern reader.
v2:
- add driver developer notes about ethtool stat count and reset
- replace Ethernet with IEEE 802.3 to better indicate source of attrs
- mention byte counters don't count FCS
- clarify RX counter is from device to host
- drop "sightly" from sysfs paragraph
- add examples of ethtool stats
- s/incoming/received/ s/incoming/transmitted/
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-09-04 02:14:31 +03:00
|
|
|
__u64 rx_over_errors;
|
|
|
|
__u64 rx_crc_errors;
|
|
|
|
__u64 rx_frame_errors;
|
|
|
|
__u64 rx_fifo_errors;
|
|
|
|
__u64 rx_missed_errors;
|
2012-10-13 13:46:48 +04:00
|
|
|
|
|
|
|
/* detailed tx_errors */
|
|
|
|
__u64 tx_aborted_errors;
|
|
|
|
__u64 tx_carrier_errors;
|
|
|
|
__u64 tx_fifo_errors;
|
|
|
|
__u64 tx_heartbeat_errors;
|
|
|
|
__u64 tx_window_errors;
|
|
|
|
|
|
|
|
/* for cslip etc */
|
|
|
|
__u64 rx_compressed;
|
|
|
|
__u64 tx_compressed;
|
net: tighten the definition of interface statistics
This patch is born out of an investigation into which IEEE statistics
correspond to which struct rtnl_link_stats64 members. Turns out that
there seems to be reasonable consensus on the matter, among many drivers.
To save others the time (and it took more time than I'm comfortable
admitting) I'm adding comments referring to IEEE attributes to
struct rtnl_link_stats64.
Up until now we had two forms of documentation for stats - in
Documentation/ABI/testing/sysfs-class-net-statistics and the comments
on struct rtnl_link_stats64 itself. While the former is very cautious
in defining the expected behavior, the latter feel quite dated and
may not be easy to understand for modern day driver author
(e.g. rx_over_errors). At the same time modern systems are far more
complex and once obvious definitions lost their clarity. For example
- does rx_packet count at the MAC layer (aFramesReceivedOK)?
packets processed correctly by hardware? received by the driver?
or maybe received by the stack?
I tried to clarify the expectations, further clarifications from
others are very welcome.
The part hardest to untangle is rx_over_errors vs rx_fifo_errors
vs rx_missed_errors. After much deliberation I concluded that for
modern HW only two of the counters will make sense. The distinction
between internal FIFO overflow and packets dropped due to back-pressure
from the host is likely too implementation (driver and device) specific
to expose in the standard stats.
Now - which two of those counters we select to use is anyone's pick:
sysfs documentation suggests rx_over_errors counts packets which
did not fit into buffers due to MTU being too small, which I reused.
There don't seem to be many modern drivers using it (well, CAN drivers
seem to love this statistic).
Of the remaining two I picked rx_missed_errors to report device drops.
bnxt reports it and it's folded into "drop"s in procfs (while
rx_fifo_errors is an error, and modern devices usually receive the frame
OK, they just can't admit it into the pipeline).
Of the drivers I looked at only AMD Lance-like and NS8390-like use all
three of these counters. rx_missed_errors counts missed frames,
rx_over_errors counts overflow events, and rx_fifo_errors counts frames
which were truncated because they didn't fit into buffers. This suggests
that rx_fifo_errors may be the correct stat for truncated packets, but
I'd think a FIFO stat counting truncated packets would be very confusing
to a modern reader.
v2:
- add driver developer notes about ethtool stat count and reset
- replace Ethernet with IEEE 802.3 to better indicate source of attrs
- mention byte counters don't count FCS
- clarify RX counter is from device to host
- drop "sightly" from sysfs paragraph
- add examples of ethtool stats
- s/incoming/received/ s/incoming/transmitted/
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-09-04 02:14:31 +03:00
|
|
|
__u64 rx_nohandler;
|
2022-04-06 20:26:00 +03:00
|
|
|
|
|
|
|
__u64 rx_otherhost_dropped;
|
2012-10-13 13:46:48 +04:00
|
|
|
};
|
|
|
|
|
net: dev: Add hardware stats support
Offloading switch device drivers may be able to collect statistics of the
traffic taking place in the HW datapath that pertains to a certain soft
netdevice, such as VLAN. Add the necessary infrastructure to allow exposing
these statistics to the offloaded netdevice in question. The API was shaped
by the following considerations:
- Collection of HW statistics is not free: there may be a finite number of
counters, and the act of counting may have a performance impact. It is
therefore necessary to allow toggling whether HW counting should be done
for any particular SW netdevice.
- As the drivers are loaded and removed, a particular device may get
offloaded and unoffloaded again. At the same time, the statistics values
need to stay monotonic (modulo the eventual 64-bit wraparound),
increasing only to reflect traffic measured in the device.
To that end, the netdevice keeps around a lazily-allocated copy of struct
rtnl_link_stats64. Device drivers then contribute to the values kept
therein at various points. Even as the driver goes away, the struct stays
around to maintain the statistics values.
- Different HW devices may be able to count different things. The
motivation behind this patch in particular is exposure of HW counters on
Nvidia Spectrum switches, where the only practical approach to counting
traffic on offloaded soft netdevices currently is to use router interface
counters, and count L3 traffic. Correspondingly that is the statistics
suite added in this patch.
Other devices may be able to measure different kinds of traffic, and for
that reason, the APIs are built to allow uniform access to different
statistics suites.
- Because soft netdevices and offloading drivers are only loosely bound, a
netdevice uses a notifier chain to communicate with the drivers. Several
new notifiers, NETDEV_OFFLOAD_XSTATS_*, have been added to carry messages
to the offloading drivers.
- Devices can have various conditions for when a particular counter is
available. As the device is configured and reconfigured, the device
offload may become or cease being suitable for counter binding. A
netdevice can use a notifier type NETDEV_OFFLOAD_XSTATS_REPORT_USED to
ping offloading drivers and determine whether anyone currently implements
a given statistics suite. This information can then be propagated to user
space.
When the driver decides to unoffload a netdevice, it can use a
newly-added function, netdev_offload_xstats_report_delta(), to record
outstanding collected statistics, before destroying the HW counter.
This patch adds a helper, call_netdevice_notifiers_info_robust(), for
dispatching a notifier with the possibility of unwind when one of the
consumers bails. Given the wish to eventually get rid of the global
notifier block altogether, this helper only invokes the per-netns notifier
block.
Signed-off-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2022-03-02 19:31:20 +03:00
|
|
|
/* Subset of link stats useful for in-HW collection. Meaning of the fields is as
|
|
|
|
* for struct rtnl_link_stats64.
|
|
|
|
*/
|
|
|
|
struct rtnl_hw_stats64 {
|
|
|
|
__u64 rx_packets;
|
|
|
|
__u64 tx_packets;
|
|
|
|
__u64 rx_bytes;
|
|
|
|
__u64 tx_bytes;
|
|
|
|
__u64 rx_errors;
|
|
|
|
__u64 tx_errors;
|
|
|
|
__u64 rx_dropped;
|
|
|
|
__u64 tx_dropped;
|
|
|
|
__u64 multicast;
|
|
|
|
};
|
|
|
|
|
2012-10-13 13:46:48 +04:00
|
|
|
/* The struct should be in sync with struct ifmap */
|
|
|
|
struct rtnl_link_ifmap {
|
|
|
|
__u64 mem_start;
|
|
|
|
__u64 mem_end;
|
|
|
|
__u64 base_addr;
|
|
|
|
__u16 irq;
|
|
|
|
__u8 dma;
|
|
|
|
__u8 port;
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* IFLA_AF_SPEC
|
|
|
|
* Contains nested attributes for address family specific attributes.
|
|
|
|
* Each address family may create a attribute with the address family
|
|
|
|
* number as type and create its own attribute structure in it.
|
|
|
|
*
|
|
|
|
* Example:
|
|
|
|
* [IFLA_AF_SPEC] = {
|
|
|
|
* [AF_INET] = {
|
|
|
|
* [IFLA_INET_CONF] = ...,
|
|
|
|
* },
|
|
|
|
* [AF_INET6] = {
|
|
|
|
* [IFLA_INET6_FLAGS] = ...,
|
|
|
|
* [IFLA_INET6_CONF] = ...,
|
|
|
|
* }
|
|
|
|
* }
|
|
|
|
*/
|
|
|
|
|
|
|
|
enum {
|
|
|
|
IFLA_UNSPEC,
|
|
|
|
IFLA_ADDRESS,
|
|
|
|
IFLA_BROADCAST,
|
|
|
|
IFLA_IFNAME,
|
|
|
|
IFLA_MTU,
|
|
|
|
IFLA_LINK,
|
|
|
|
IFLA_QDISC,
|
|
|
|
IFLA_STATS,
|
|
|
|
IFLA_COST,
|
|
|
|
#define IFLA_COST IFLA_COST
|
|
|
|
IFLA_PRIORITY,
|
|
|
|
#define IFLA_PRIORITY IFLA_PRIORITY
|
|
|
|
IFLA_MASTER,
|
|
|
|
#define IFLA_MASTER IFLA_MASTER
|
|
|
|
IFLA_WIRELESS, /* Wireless Extension event - see wireless.h */
|
|
|
|
#define IFLA_WIRELESS IFLA_WIRELESS
|
|
|
|
IFLA_PROTINFO, /* Protocol specific information for a link */
|
|
|
|
#define IFLA_PROTINFO IFLA_PROTINFO
|
|
|
|
IFLA_TXQLEN,
|
|
|
|
#define IFLA_TXQLEN IFLA_TXQLEN
|
|
|
|
IFLA_MAP,
|
|
|
|
#define IFLA_MAP IFLA_MAP
|
|
|
|
IFLA_WEIGHT,
|
|
|
|
#define IFLA_WEIGHT IFLA_WEIGHT
|
|
|
|
IFLA_OPERSTATE,
|
|
|
|
IFLA_LINKMODE,
|
|
|
|
IFLA_LINKINFO,
|
|
|
|
#define IFLA_LINKINFO IFLA_LINKINFO
|
|
|
|
IFLA_NET_NS_PID,
|
|
|
|
IFLA_IFALIAS,
|
|
|
|
IFLA_NUM_VF, /* Number of VFs if device is SR-IOV PF */
|
|
|
|
IFLA_VFINFO_LIST,
|
|
|
|
IFLA_STATS64,
|
|
|
|
IFLA_VF_PORTS,
|
|
|
|
IFLA_PORT_SELF,
|
|
|
|
IFLA_AF_SPEC,
|
|
|
|
IFLA_GROUP, /* Group the device belongs to */
|
|
|
|
IFLA_NET_NS_FD,
|
|
|
|
IFLA_EXT_MASK, /* Extended info mask, VFs, etc */
|
|
|
|
IFLA_PROMISCUITY, /* Promiscuity count: > 0 means acts PROMISC */
|
|
|
|
#define IFLA_PROMISCUITY IFLA_PROMISCUITY
|
|
|
|
IFLA_NUM_TX_QUEUES,
|
|
|
|
IFLA_NUM_RX_QUEUES,
|
2012-12-28 03:49:39 +04:00
|
|
|
IFLA_CARRIER,
|
2013-07-29 20:16:50 +04:00
|
|
|
IFLA_PHYS_PORT_ID,
|
2014-03-29 20:48:35 +04:00
|
|
|
IFLA_CARRIER_CHANGES,
|
2014-11-28 16:34:18 +03:00
|
|
|
IFLA_PHYS_SWITCH_ID,
|
2015-01-15 17:11:16 +03:00
|
|
|
IFLA_LINK_NETNSID,
|
2015-03-18 05:23:15 +03:00
|
|
|
IFLA_PHYS_PORT_NAME,
|
2015-07-14 23:43:20 +03:00
|
|
|
IFLA_PROTO_DOWN,
|
2016-03-21 19:55:10 +03:00
|
|
|
IFLA_GSO_MAX_SEGS,
|
|
|
|
IFLA_GSO_MAX_SIZE,
|
2016-04-19 21:30:10 +03:00
|
|
|
IFLA_PAD,
|
2016-07-19 22:16:49 +03:00
|
|
|
IFLA_XDP,
|
2017-05-27 17:14:34 +03:00
|
|
|
IFLA_EVENT,
|
2017-10-03 14:53:23 +03:00
|
|
|
IFLA_NEW_NETNSID,
|
2017-11-02 22:04:38 +03:00
|
|
|
IFLA_IF_NETNSID,
|
2018-09-04 22:53:52 +03:00
|
|
|
IFLA_TARGET_NETNSID = IFLA_IF_NETNSID, /* new alias */
|
2018-01-18 20:59:13 +03:00
|
|
|
IFLA_CARRIER_UP_COUNT,
|
|
|
|
IFLA_CARRIER_DOWN_COUNT,
|
2018-01-25 17:01:39 +03:00
|
|
|
IFLA_NEW_IFINDEX,
|
2018-07-27 23:43:22 +03:00
|
|
|
IFLA_MIN_MTU,
|
|
|
|
IFLA_MAX_MTU,
|
2019-09-30 12:48:16 +03:00
|
|
|
IFLA_PROP_LIST,
|
|
|
|
IFLA_ALT_IFNAME, /* Alternative ifname */
|
2019-12-11 12:58:14 +03:00
|
|
|
IFLA_PERM_ADDRESS,
|
2020-08-01 03:34:01 +03:00
|
|
|
IFLA_PROTO_DOWN_REASON,
|
rtnetlink: add IFLA_PARENT_[DEV|DEV_BUS]_NAME
In some cases, for example in the upcoming WWAN framework changes,
there's no natural "parent netdev", so sometimes dummy netdevs are
created or similar. IFLA_PARENT_DEV_NAME is a new attribute intended to
contain a device (sysfs, struct device) name that can be used instead
when creating a new netdev, if the rtnetlink family implements it.
As suggested by Parav Pandit, we also introduce IFLA_PARENT_DEV_BUS_NAME
attribute in order to uniquely identify a device on the system (with
bus/name pair).
ip-link(8) support for the generic parent device attributes will help
us avoid code duplication, so no other link type will require a custom
code to handle the parent name attribute. E.g. the WWAN interface
creation command will looks like this:
$ ip link add wwan0-1 parent-dev wwan0 type wwan channel-id 1
So, some future subsystem (or driver) FOO will have an interface
creation command that looks like this:
$ ip link add foo1-3 parent-dev foo1 type foo bar-id 3 baz-type Y
Below is an example of dumping link info of a random device with these
new attributes:
$ ip --details link show wlp0s20f3
4: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UP mode DORMANT group default qlen 1000
...
parent_bus pci parent_dev 0000:00:14.3
Co-developed-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
Co-developed-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Suggested-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-12 11:20:55 +03:00
|
|
|
|
|
|
|
/* device (sysfs) name as parent, used instead
|
|
|
|
* of IFLA_LINK where there's no parent netdev
|
|
|
|
*/
|
|
|
|
IFLA_PARENT_DEV_NAME,
|
|
|
|
IFLA_PARENT_DEV_BUS_NAME,
|
2022-01-05 13:48:38 +03:00
|
|
|
IFLA_GRO_MAX_SIZE,
|
2022-05-13 21:33:56 +03:00
|
|
|
IFLA_TSO_MAX_SIZE,
|
|
|
|
IFLA_TSO_MAX_SEGS,
|
rtnetlink: add IFLA_PARENT_[DEV|DEV_BUS]_NAME
In some cases, for example in the upcoming WWAN framework changes,
there's no natural "parent netdev", so sometimes dummy netdevs are
created or similar. IFLA_PARENT_DEV_NAME is a new attribute intended to
contain a device (sysfs, struct device) name that can be used instead
when creating a new netdev, if the rtnetlink family implements it.
As suggested by Parav Pandit, we also introduce IFLA_PARENT_DEV_BUS_NAME
attribute in order to uniquely identify a device on the system (with
bus/name pair).
ip-link(8) support for the generic parent device attributes will help
us avoid code duplication, so no other link type will require a custom
code to handle the parent name attribute. E.g. the WWAN interface
creation command will looks like this:
$ ip link add wwan0-1 parent-dev wwan0 type wwan channel-id 1
So, some future subsystem (or driver) FOO will have an interface
creation command that looks like this:
$ ip link add foo1-3 parent-dev foo1 type foo bar-id 3 baz-type Y
Below is an example of dumping link info of a random device with these
new attributes:
$ ip --details link show wlp0s20f3
4: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UP mode DORMANT group default qlen 1000
...
parent_bus pci parent_dev 0000:00:14.3
Co-developed-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
Co-developed-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Suggested-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-12 11:20:55 +03:00
|
|
|
|
2012-10-13 13:46:48 +04:00
|
|
|
__IFLA_MAX
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
#define IFLA_MAX (__IFLA_MAX - 1)
|
|
|
|
|
2020-08-01 03:34:01 +03:00
|
|
|
enum {
|
|
|
|
IFLA_PROTO_DOWN_REASON_UNSPEC,
|
|
|
|
IFLA_PROTO_DOWN_REASON_MASK, /* u32, mask for reason bits */
|
|
|
|
IFLA_PROTO_DOWN_REASON_VALUE, /* u32, reason bit value */
|
|
|
|
|
|
|
|
__IFLA_PROTO_DOWN_REASON_CNT,
|
|
|
|
IFLA_PROTO_DOWN_REASON_MAX = __IFLA_PROTO_DOWN_REASON_CNT - 1
|
|
|
|
};
|
|
|
|
|
2012-10-13 13:46:48 +04:00
|
|
|
/* backwards compatibility for userspace */
|
|
|
|
#ifndef __KERNEL__
|
|
|
|
#define IFLA_RTA(r) ((struct rtattr*)(((char*)(r)) + NLMSG_ALIGN(sizeof(struct ifinfomsg))))
|
|
|
|
#define IFLA_PAYLOAD(n) NLMSG_PAYLOAD(n,sizeof(struct ifinfomsg))
|
|
|
|
#endif
|
|
|
|
|
|
|
|
enum {
|
|
|
|
IFLA_INET_UNSPEC,
|
|
|
|
IFLA_INET_CONF,
|
|
|
|
__IFLA_INET_MAX,
|
|
|
|
};
|
|
|
|
|
|
|
|
#define IFLA_INET_MAX (__IFLA_INET_MAX - 1)
|
|
|
|
|
|
|
|
/* ifi_flags.
|
|
|
|
|
|
|
|
IFF_* flags.
|
|
|
|
|
|
|
|
The only change is:
|
|
|
|
IFF_LOOPBACK, IFF_BROADCAST and IFF_POINTOPOINT are
|
|
|
|
more not changeable by user. They describe link media
|
|
|
|
characteristics and set by device driver.
|
|
|
|
|
|
|
|
Comments:
|
|
|
|
- Combination IFF_BROADCAST|IFF_POINTOPOINT is invalid
|
|
|
|
- If neither of these three flags are set;
|
|
|
|
the interface is NBMA.
|
|
|
|
|
|
|
|
- IFF_MULTICAST does not mean anything special:
|
|
|
|
multicasts can be used on all not-NBMA links.
|
|
|
|
IFF_MULTICAST means that this media uses special encapsulation
|
|
|
|
for multicast frames. Apparently, all IFF_POINTOPOINT and
|
|
|
|
IFF_BROADCAST devices are able to use multicasts too.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* IFLA_LINK.
|
|
|
|
For usual devices it is equal ifi_index.
|
|
|
|
If it is a "virtual interface" (f.e. tunnel), ifi_link
|
|
|
|
can point to real physical interface (f.e. for bandwidth calculations),
|
|
|
|
or maybe 0, what means, that real media is unknown (usual
|
|
|
|
for IPIP tunnels, when route to endpoint is allowed to change)
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* Subtype attributes for IFLA_PROTINFO */
|
|
|
|
enum {
|
|
|
|
IFLA_INET6_UNSPEC,
|
|
|
|
IFLA_INET6_FLAGS, /* link flags */
|
|
|
|
IFLA_INET6_CONF, /* sysctl parameters */
|
|
|
|
IFLA_INET6_STATS, /* statistics */
|
|
|
|
IFLA_INET6_MCAST, /* MC things. What of them? */
|
|
|
|
IFLA_INET6_CACHEINFO, /* time values and max reasm size */
|
|
|
|
IFLA_INET6_ICMP6STATS, /* statistics (icmpv6) */
|
net: ipv6: add tokenized interface identifier support
This patch adds support for IPv6 tokenized IIDs, that allow
for administrators to assign well-known host-part addresses
to nodes whilst still obtaining global network prefix from
Router Advertisements. It is currently in draft status.
The primary target for such support is server platforms
where addresses are usually manually configured, rather
than using DHCPv6 or SLAAC. By using tokenised identifiers,
hosts can still determine their network prefix by use of
SLAAC, but more readily be automatically renumbered should
their network prefix change. [...]
The disadvantage with static addresses is that they are
likely to require manual editing should the network prefix
in use change. If instead there were a method to only
manually configure the static identifier part of the IPv6
address, then the address could be automatically updated
when a new prefix was introduced, as described in [RFC4192]
for example. In such cases a DNS server might be
configured with such a tokenised interface identifier of
::53, and SLAAC would use the token in constructing the
interface address, using the advertised prefix. [...]
http://tools.ietf.org/html/draft-chown-6man-tokenised-ipv6-identifiers-02
The implementation is partially based on top of Mark K.
Thompson's proof of concept. However, it uses the Netlink
interface for configuration resp. data retrival, so that
it can be easily extended in future. Successfully tested
by myself.
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Cc: Thomas Graf <tgraf@suug.ch>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-04-08 08:01:30 +04:00
|
|
|
IFLA_INET6_TOKEN, /* device token */
|
2014-07-11 23:10:18 +04:00
|
|
|
IFLA_INET6_ADDR_GEN_MODE, /* implicit address generator mode */
|
ipv6: add IFLA_INET6_RA_MTU to expose mtu value
The kernel provides a "/proc/sys/net/ipv6/conf/<iface>/mtu"
file, which can temporarily record the mtu value of the last
received RA message when the RA mtu value is lower than the
interface mtu, but this proc has following limitations:
(1) when the interface mtu (/sys/class/net/<iface>/mtu) is
updeated, mtu6 (/proc/sys/net/ipv6/conf/<iface>/mtu) will
be updated to the value of interface mtu;
(2) mtu6 (/proc/sys/net/ipv6/conf/<iface>/mtu) only affect
ipv6 connection, and not affect ipv4.
Therefore, when the mtu option is carried in the RA message,
there will be a problem that the user sometimes cannot obtain
RA mtu value correctly by reading mtu6.
After this patch set, if a RA message carries the mtu option,
you can send a netlink msg which nlmsg_type is RTM_GETLINK,
and then by parsing the attribute of IFLA_INET6_RA_MTU to
get the mtu value carried in the RA message received on the
inet6 device. In addition, you can also get a link notification
when ra_mtu is updated so it doesn't have to poll.
In this way, if the MTU values that the device receives from
the network in the PCO IPv4 and the RA IPv6 procedures are
different, the user can obtain the correct ipv6 ra_mtu value
and compare the value of ra_mtu and ipv4 mtu, then the device
can use the lower MTU value for both IPv4 and IPv6.
Signed-off-by: Rocco Yue <rocco.yue@mediatek.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Link: https://lore.kernel.org/r/20210827150412.9267-1-rocco.yue@mediatek.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-08-27 18:04:12 +03:00
|
|
|
IFLA_INET6_RA_MTU, /* mtu carried in the RA message */
|
2012-10-13 13:46:48 +04:00
|
|
|
__IFLA_INET6_MAX
|
|
|
|
};
|
|
|
|
|
|
|
|
#define IFLA_INET6_MAX (__IFLA_INET6_MAX - 1)
|
|
|
|
|
2014-07-11 23:10:18 +04:00
|
|
|
enum in6_addr_gen_mode {
|
|
|
|
IN6_ADDR_GEN_MODE_EUI64,
|
|
|
|
IN6_ADDR_GEN_MODE_NONE,
|
ipv6: generation of stable privacy addresses for link-local and autoconf
This patch implements the stable privacy address generation for
link-local and autoconf addresses as specified in RFC7217.
RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key)
is the RID (random identifier). As the hash function F we chose one
round of sha1. Prefix will be either the link-local prefix or the
router advertised one. As Net_Iface we use the MAC address of the
device. DAD_Counter and secret_key are implemented as specified.
We don't use Network_ID, as it couples the code too closely to other
subsystems. It is specified as optional in the RFC.
As Net_Iface we only use the MAC address: we simply have no stable
identifier in the kernel we could possibly use: because this code might
run very early, we cannot depend on names, as they might be changed by
user space early on during the boot process.
A new address generation mode is introduced,
IN6_ADDR_GEN_MODE_STABLE_PRIVACY. With iproute2 one can switch back to
none or eui64 address configuration mode although the stable_secret is
already set.
We refuse writes to ipv6/conf/all/stable_secret but only allow
ipv6/conf/default/stable_secret and the interface specific file to be
written to. The default stable_secret is used as the parameter for the
namespace, the interface specific can overwrite the secret, e.g. when
switching a network configuration from one system to another while
inheriting the secret.
Cc: Erik Kline <ek@google.com>
Cc: Fernando Gont <fgont@si6networks.com>
Cc: Lorenzo Colitti <lorenzo@google.com>
Cc: YOSHIFUJI Hideaki/吉藤英明 <hideaki.yoshifuji@miraclelinux.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-03-24 01:36:01 +03:00
|
|
|
IN6_ADDR_GEN_MODE_STABLE_PRIVACY,
|
2015-12-16 18:44:38 +03:00
|
|
|
IN6_ADDR_GEN_MODE_RANDOM,
|
2014-07-11 23:10:18 +04:00
|
|
|
};
|
|
|
|
|
2014-09-05 17:51:31 +04:00
|
|
|
/* Bridge section */
|
|
|
|
|
|
|
|
enum {
|
|
|
|
IFLA_BR_UNSPEC,
|
|
|
|
IFLA_BR_FORWARD_DELAY,
|
|
|
|
IFLA_BR_HELLO_TIME,
|
|
|
|
IFLA_BR_MAX_AGE,
|
2015-03-18 12:06:58 +03:00
|
|
|
IFLA_BR_AGEING_TIME,
|
|
|
|
IFLA_BR_STP_STATE,
|
|
|
|
IFLA_BR_PRIORITY,
|
2015-08-07 19:40:45 +03:00
|
|
|
IFLA_BR_VLAN_FILTERING,
|
2015-08-27 09:32:26 +03:00
|
|
|
IFLA_BR_VLAN_PROTOCOL,
|
2015-10-04 15:23:28 +03:00
|
|
|
IFLA_BR_GROUP_FWD_MASK,
|
2015-10-04 15:23:29 +03:00
|
|
|
IFLA_BR_ROOT_ID,
|
2015-10-04 15:23:30 +03:00
|
|
|
IFLA_BR_BRIDGE_ID,
|
2015-10-04 15:23:31 +03:00
|
|
|
IFLA_BR_ROOT_PORT,
|
2015-10-04 15:23:32 +03:00
|
|
|
IFLA_BR_ROOT_PATH_COST,
|
2015-10-04 15:23:33 +03:00
|
|
|
IFLA_BR_TOPOLOGY_CHANGE,
|
|
|
|
IFLA_BR_TOPOLOGY_CHANGE_DETECTED,
|
2015-10-04 15:23:34 +03:00
|
|
|
IFLA_BR_HELLO_TIMER,
|
|
|
|
IFLA_BR_TCN_TIMER,
|
|
|
|
IFLA_BR_TOPOLOGY_CHANGE_TIMER,
|
|
|
|
IFLA_BR_GC_TIMER,
|
2015-10-04 15:23:35 +03:00
|
|
|
IFLA_BR_GROUP_ADDR,
|
2015-10-04 15:23:36 +03:00
|
|
|
IFLA_BR_FDB_FLUSH,
|
2015-10-04 15:23:37 +03:00
|
|
|
IFLA_BR_MCAST_ROUTER,
|
2015-10-04 15:23:38 +03:00
|
|
|
IFLA_BR_MCAST_SNOOPING,
|
2015-10-04 15:23:39 +03:00
|
|
|
IFLA_BR_MCAST_QUERY_USE_IFADDR,
|
2015-10-04 15:23:40 +03:00
|
|
|
IFLA_BR_MCAST_QUERIER,
|
2015-10-04 15:23:41 +03:00
|
|
|
IFLA_BR_MCAST_HASH_ELASTICITY,
|
2015-10-04 15:23:42 +03:00
|
|
|
IFLA_BR_MCAST_HASH_MAX,
|
2015-10-04 15:23:43 +03:00
|
|
|
IFLA_BR_MCAST_LAST_MEMBER_CNT,
|
2015-10-04 15:23:44 +03:00
|
|
|
IFLA_BR_MCAST_STARTUP_QUERY_CNT,
|
2015-10-04 15:23:45 +03:00
|
|
|
IFLA_BR_MCAST_LAST_MEMBER_INTVL,
|
|
|
|
IFLA_BR_MCAST_MEMBERSHIP_INTVL,
|
|
|
|
IFLA_BR_MCAST_QUERIER_INTVL,
|
|
|
|
IFLA_BR_MCAST_QUERY_INTVL,
|
|
|
|
IFLA_BR_MCAST_QUERY_RESPONSE_INTVL,
|
|
|
|
IFLA_BR_MCAST_STARTUP_QUERY_INTVL,
|
2015-10-04 15:23:46 +03:00
|
|
|
IFLA_BR_NF_CALL_IPTABLES,
|
|
|
|
IFLA_BR_NF_CALL_IP6TABLES,
|
|
|
|
IFLA_BR_NF_CALL_ARPTABLES,
|
2015-10-04 15:23:47 +03:00
|
|
|
IFLA_BR_VLAN_DEFAULT_PVID,
|
2016-04-25 11:25:18 +03:00
|
|
|
IFLA_BR_PAD,
|
2016-04-30 11:25:28 +03:00
|
|
|
IFLA_BR_VLAN_STATS_ENABLED,
|
2016-06-28 17:57:06 +03:00
|
|
|
IFLA_BR_MCAST_STATS_ENABLED,
|
2016-11-21 15:03:24 +03:00
|
|
|
IFLA_BR_MCAST_IGMP_VERSION,
|
2016-11-21 15:03:25 +03:00
|
|
|
IFLA_BR_MCAST_MLD_VERSION,
|
2018-10-12 13:41:16 +03:00
|
|
|
IFLA_BR_VLAN_STATS_PER_PORT,
|
2018-11-24 05:34:20 +03:00
|
|
|
IFLA_BR_MULTI_BOOLOPT,
|
2021-08-13 18:00:00 +03:00
|
|
|
IFLA_BR_MCAST_QUERIER_STATE,
|
2014-09-05 17:51:31 +04:00
|
|
|
__IFLA_BR_MAX,
|
|
|
|
};
|
|
|
|
|
|
|
|
#define IFLA_BR_MAX (__IFLA_BR_MAX - 1)
|
|
|
|
|
2015-10-04 15:23:29 +03:00
|
|
|
struct ifla_bridge_id {
|
|
|
|
__u8 prio[2];
|
|
|
|
__u8 addr[6]; /* ETH_ALEN */
|
|
|
|
};
|
|
|
|
|
2012-11-13 11:53:05 +04:00
|
|
|
enum {
|
|
|
|
BRIDGE_MODE_UNSPEC,
|
|
|
|
BRIDGE_MODE_HAIRPIN,
|
|
|
|
};
|
|
|
|
|
|
|
|
enum {
|
|
|
|
IFLA_BRPORT_UNSPEC,
|
|
|
|
IFLA_BRPORT_STATE, /* Spanning tree state */
|
|
|
|
IFLA_BRPORT_PRIORITY, /* " priority */
|
|
|
|
IFLA_BRPORT_COST, /* " cost */
|
|
|
|
IFLA_BRPORT_MODE, /* mode (hairpin) */
|
2012-11-13 11:53:07 +04:00
|
|
|
IFLA_BRPORT_GUARD, /* bpdu guard */
|
2012-11-13 11:53:08 +04:00
|
|
|
IFLA_BRPORT_PROTECT, /* root port protection */
|
2012-12-06 01:24:45 +04:00
|
|
|
IFLA_BRPORT_FAST_LEAVE, /* multicast fast leave */
|
2013-06-05 18:08:00 +04:00
|
|
|
IFLA_BRPORT_LEARNING, /* mac learning */
|
2013-06-05 18:08:01 +04:00
|
|
|
IFLA_BRPORT_UNICAST_FLOOD, /* flood unicast traffic */
|
2014-10-24 01:49:17 +04:00
|
|
|
IFLA_BRPORT_PROXYARP, /* proxy ARP */
|
2014-11-28 16:34:23 +03:00
|
|
|
IFLA_BRPORT_LEARNING_SYNC, /* mac learning sync from device */
|
2015-03-04 13:54:21 +03:00
|
|
|
IFLA_BRPORT_PROXYARP_WIFI, /* proxy ARP for Wi-Fi */
|
2015-10-06 15:11:55 +03:00
|
|
|
IFLA_BRPORT_ROOT_ID, /* designated root */
|
2015-10-06 15:11:56 +03:00
|
|
|
IFLA_BRPORT_BRIDGE_ID, /* designated bridge */
|
2015-10-06 15:11:57 +03:00
|
|
|
IFLA_BRPORT_DESIGNATED_PORT,
|
|
|
|
IFLA_BRPORT_DESIGNATED_COST,
|
2015-10-06 15:11:58 +03:00
|
|
|
IFLA_BRPORT_ID,
|
|
|
|
IFLA_BRPORT_NO,
|
2015-10-06 15:11:59 +03:00
|
|
|
IFLA_BRPORT_TOPOLOGY_CHANGE_ACK,
|
|
|
|
IFLA_BRPORT_CONFIG_PENDING,
|
2015-10-06 15:12:00 +03:00
|
|
|
IFLA_BRPORT_MESSAGE_AGE_TIMER,
|
|
|
|
IFLA_BRPORT_FORWARD_DELAY_TIMER,
|
|
|
|
IFLA_BRPORT_HOLD_TIMER,
|
2015-10-06 15:12:01 +03:00
|
|
|
IFLA_BRPORT_FLUSH,
|
2015-10-06 15:12:02 +03:00
|
|
|
IFLA_BRPORT_MULTICAST_ROUTER,
|
2016-04-25 11:25:18 +03:00
|
|
|
IFLA_BRPORT_PAD,
|
2016-08-31 16:36:52 +03:00
|
|
|
IFLA_BRPORT_MCAST_FLOOD,
|
2017-01-21 23:01:32 +03:00
|
|
|
IFLA_BRPORT_MCAST_TO_UCAST,
|
2017-02-01 09:59:53 +03:00
|
|
|
IFLA_BRPORT_VLAN_TUNNEL,
|
2017-04-26 16:48:09 +03:00
|
|
|
IFLA_BRPORT_BCAST_FLOOD,
|
2017-09-27 16:12:44 +03:00
|
|
|
IFLA_BRPORT_GROUP_FWD_MASK,
|
2017-10-07 08:12:37 +03:00
|
|
|
IFLA_BRPORT_NEIGH_SUPPRESS,
|
2018-05-24 11:56:48 +03:00
|
|
|
IFLA_BRPORT_ISOLATED,
|
2018-07-23 11:16:59 +03:00
|
|
|
IFLA_BRPORT_BACKUP_PORT,
|
2020-04-26 16:22:01 +03:00
|
|
|
IFLA_BRPORT_MRP_RING_OPEN,
|
2020-07-14 10:34:58 +03:00
|
|
|
IFLA_BRPORT_MRP_IN_OPEN,
|
2021-01-26 12:35:33 +03:00
|
|
|
IFLA_BRPORT_MCAST_EHT_HOSTS_LIMIT,
|
|
|
|
IFLA_BRPORT_MCAST_EHT_HOSTS_CNT,
|
2022-02-23 13:16:46 +03:00
|
|
|
IFLA_BRPORT_LOCKED,
|
2012-11-13 11:53:05 +04:00
|
|
|
__IFLA_BRPORT_MAX
|
|
|
|
};
|
|
|
|
#define IFLA_BRPORT_MAX (__IFLA_BRPORT_MAX - 1)
|
|
|
|
|
2012-10-13 13:46:48 +04:00
|
|
|
struct ifla_cacheinfo {
|
|
|
|
__u32 max_reasm_len;
|
|
|
|
__u32 tstamp; /* ipv6InterfaceTable updated timestamp */
|
|
|
|
__u32 reachable_time;
|
|
|
|
__u32 retrans_time;
|
|
|
|
};
|
|
|
|
|
|
|
|
enum {
|
|
|
|
IFLA_INFO_UNSPEC,
|
|
|
|
IFLA_INFO_KIND,
|
|
|
|
IFLA_INFO_DATA,
|
|
|
|
IFLA_INFO_XSTATS,
|
2014-01-22 12:05:55 +04:00
|
|
|
IFLA_INFO_SLAVE_KIND,
|
|
|
|
IFLA_INFO_SLAVE_DATA,
|
2012-10-13 13:46:48 +04:00
|
|
|
__IFLA_INFO_MAX,
|
|
|
|
};
|
|
|
|
|
|
|
|
#define IFLA_INFO_MAX (__IFLA_INFO_MAX - 1)
|
|
|
|
|
|
|
|
/* VLAN section */
|
|
|
|
|
|
|
|
enum {
|
|
|
|
IFLA_VLAN_UNSPEC,
|
|
|
|
IFLA_VLAN_ID,
|
|
|
|
IFLA_VLAN_FLAGS,
|
|
|
|
IFLA_VLAN_EGRESS_QOS,
|
|
|
|
IFLA_VLAN_INGRESS_QOS,
|
net: vlan: add 802.1ad support
Add support for 802.1ad VLAN devices. This mainly consists of checking for
ETH_P_8021AD in addition to ETH_P_8021Q in a couple of places and check
offloading capabilities based on the used protocol.
Configuration is done using "ip link":
# ip link add link eth0 eth0.1000 \
type vlan proto 802.1ad id 1000
# ip link add link eth0.1000 eth0.1000.1000 \
type vlan proto 802.1q id 1000
52:54:00:12:34:56 > 92:b1:54:28:e4:8c, ethertype 802.1Q (0x8100), length 106: vlan 1000, p 0, ethertype 802.1Q, vlan 1000, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
20.1.0.2 > 20.1.0.1: ICMP echo request, id 3003, seq 8, length 64
92:b1:54:28:e4:8c > 52:54:00:12:34:56, ethertype 802.1Q-QinQ (0x88a8), length 106: vlan 1000, p 0, ethertype 802.1Q, vlan 1000, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 47944, offset 0, flags [none], proto ICMP (1), length 84)
20.1.0.1 > 20.1.0.2: ICMP echo reply, id 3003, seq 8, length 64
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-04-19 06:04:31 +04:00
|
|
|
IFLA_VLAN_PROTOCOL,
|
2012-10-13 13:46:48 +04:00
|
|
|
__IFLA_VLAN_MAX,
|
|
|
|
};
|
|
|
|
|
|
|
|
#define IFLA_VLAN_MAX (__IFLA_VLAN_MAX - 1)
|
|
|
|
|
|
|
|
struct ifla_vlan_flags {
|
|
|
|
__u32 flags;
|
|
|
|
__u32 mask;
|
|
|
|
};
|
|
|
|
|
|
|
|
enum {
|
|
|
|
IFLA_VLAN_QOS_UNSPEC,
|
|
|
|
IFLA_VLAN_QOS_MAPPING,
|
|
|
|
__IFLA_VLAN_QOS_MAX
|
|
|
|
};
|
|
|
|
|
|
|
|
#define IFLA_VLAN_QOS_MAX (__IFLA_VLAN_QOS_MAX - 1)
|
|
|
|
|
|
|
|
struct ifla_vlan_qos_mapping {
|
|
|
|
__u32 from;
|
|
|
|
__u32 to;
|
|
|
|
};
|
|
|
|
|
|
|
|
/* MACVLAN section */
|
|
|
|
enum {
|
|
|
|
IFLA_MACVLAN_UNSPEC,
|
|
|
|
IFLA_MACVLAN_MODE,
|
|
|
|
IFLA_MACVLAN_FLAGS,
|
2014-09-25 18:31:08 +04:00
|
|
|
IFLA_MACVLAN_MACADDR_MODE,
|
|
|
|
IFLA_MACVLAN_MACADDR,
|
|
|
|
IFLA_MACVLAN_MACADDR_DATA,
|
|
|
|
IFLA_MACVLAN_MACADDR_COUNT,
|
2020-12-02 21:49:58 +03:00
|
|
|
IFLA_MACVLAN_BC_QUEUE_LEN,
|
|
|
|
IFLA_MACVLAN_BC_QUEUE_LEN_USED,
|
2012-10-13 13:46:48 +04:00
|
|
|
__IFLA_MACVLAN_MAX,
|
|
|
|
};
|
|
|
|
|
|
|
|
#define IFLA_MACVLAN_MAX (__IFLA_MACVLAN_MAX - 1)
|
|
|
|
|
|
|
|
enum macvlan_mode {
|
|
|
|
MACVLAN_MODE_PRIVATE = 1, /* don't talk to other macvlans */
|
|
|
|
MACVLAN_MODE_VEPA = 2, /* talk to other ports through ext bridge */
|
|
|
|
MACVLAN_MODE_BRIDGE = 4, /* talk to bridge ports directly */
|
|
|
|
MACVLAN_MODE_PASSTHRU = 8,/* take over the underlying device */
|
2014-09-25 18:31:08 +04:00
|
|
|
MACVLAN_MODE_SOURCE = 16,/* use source MAC address list to assign */
|
|
|
|
};
|
|
|
|
|
|
|
|
enum macvlan_macaddr_mode {
|
|
|
|
MACVLAN_MACADDR_ADD,
|
|
|
|
MACVLAN_MACADDR_DEL,
|
|
|
|
MACVLAN_MACADDR_FLUSH,
|
|
|
|
MACVLAN_MACADDR_SET,
|
2012-10-13 13:46:48 +04:00
|
|
|
};
|
|
|
|
|
|
|
|
#define MACVLAN_FLAG_NOPROMISC 1
|
2021-04-25 12:22:03 +03:00
|
|
|
#define MACVLAN_FLAG_NODST 2 /* skip dst macvlan if matching src macvlan */
|
2012-10-13 13:46:48 +04:00
|
|
|
|
2015-08-13 23:59:00 +03:00
|
|
|
/* VRF section */
|
|
|
|
enum {
|
|
|
|
IFLA_VRF_UNSPEC,
|
|
|
|
IFLA_VRF_TABLE,
|
|
|
|
__IFLA_VRF_MAX
|
|
|
|
};
|
|
|
|
|
|
|
|
#define IFLA_VRF_MAX (__IFLA_VRF_MAX - 1)
|
|
|
|
|
2016-02-02 18:43:45 +03:00
|
|
|
enum {
|
|
|
|
IFLA_VRF_PORT_UNSPEC,
|
|
|
|
IFLA_VRF_PORT_TABLE,
|
|
|
|
__IFLA_VRF_PORT_MAX
|
|
|
|
};
|
|
|
|
|
|
|
|
#define IFLA_VRF_PORT_MAX (__IFLA_VRF_PORT_MAX - 1)
|
|
|
|
|
2016-03-11 20:07:31 +03:00
|
|
|
/* MACSEC section */
|
|
|
|
enum {
|
|
|
|
IFLA_MACSEC_UNSPEC,
|
|
|
|
IFLA_MACSEC_SCI,
|
|
|
|
IFLA_MACSEC_PORT,
|
|
|
|
IFLA_MACSEC_ICV_LEN,
|
|
|
|
IFLA_MACSEC_CIPHER_SUITE,
|
|
|
|
IFLA_MACSEC_WINDOW,
|
|
|
|
IFLA_MACSEC_ENCODING_SA,
|
|
|
|
IFLA_MACSEC_ENCRYPT,
|
|
|
|
IFLA_MACSEC_PROTECT,
|
|
|
|
IFLA_MACSEC_INC_SCI,
|
|
|
|
IFLA_MACSEC_ES,
|
|
|
|
IFLA_MACSEC_SCB,
|
|
|
|
IFLA_MACSEC_REPLAY_PROTECT,
|
|
|
|
IFLA_MACSEC_VALIDATION,
|
2016-04-26 11:06:11 +03:00
|
|
|
IFLA_MACSEC_PAD,
|
2020-03-25 16:01:34 +03:00
|
|
|
IFLA_MACSEC_OFFLOAD,
|
2016-03-11 20:07:31 +03:00
|
|
|
__IFLA_MACSEC_MAX,
|
|
|
|
};
|
|
|
|
|
|
|
|
#define IFLA_MACSEC_MAX (__IFLA_MACSEC_MAX - 1)
|
|
|
|
|
2018-06-12 15:07:12 +03:00
|
|
|
/* XFRM section */
|
|
|
|
enum {
|
|
|
|
IFLA_XFRM_UNSPEC,
|
|
|
|
IFLA_XFRM_LINK,
|
|
|
|
IFLA_XFRM_IF_ID,
|
|
|
|
__IFLA_XFRM_MAX
|
|
|
|
};
|
|
|
|
|
|
|
|
#define IFLA_XFRM_MAX (__IFLA_XFRM_MAX - 1)
|
2016-03-11 20:07:31 +03:00
|
|
|
|
|
|
|
enum macsec_validation_type {
|
|
|
|
MACSEC_VALIDATE_DISABLED = 0,
|
|
|
|
MACSEC_VALIDATE_CHECK = 1,
|
|
|
|
MACSEC_VALIDATE_STRICT = 2,
|
|
|
|
__MACSEC_VALIDATE_END,
|
|
|
|
MACSEC_VALIDATE_MAX = __MACSEC_VALIDATE_END - 1,
|
|
|
|
};
|
|
|
|
|
2020-01-14 01:31:40 +03:00
|
|
|
enum macsec_offload {
|
|
|
|
MACSEC_OFFLOAD_OFF = 0,
|
|
|
|
MACSEC_OFFLOAD_PHY = 1,
|
2020-03-25 15:52:33 +03:00
|
|
|
MACSEC_OFFLOAD_MAC = 2,
|
2020-01-14 01:31:40 +03:00
|
|
|
__MACSEC_OFFLOAD_END,
|
|
|
|
MACSEC_OFFLOAD_MAX = __MACSEC_OFFLOAD_END - 1,
|
|
|
|
};
|
|
|
|
|
2014-11-24 10:07:46 +03:00
|
|
|
/* IPVLAN section */
|
|
|
|
enum {
|
|
|
|
IFLA_IPVLAN_UNSPEC,
|
|
|
|
IFLA_IPVLAN_MODE,
|
2017-10-27 01:09:21 +03:00
|
|
|
IFLA_IPVLAN_FLAGS,
|
2014-11-24 10:07:46 +03:00
|
|
|
__IFLA_IPVLAN_MAX
|
|
|
|
};
|
|
|
|
|
|
|
|
#define IFLA_IPVLAN_MAX (__IFLA_IPVLAN_MAX - 1)
|
|
|
|
|
|
|
|
enum ipvlan_mode {
|
|
|
|
IPVLAN_MODE_L2 = 0,
|
|
|
|
IPVLAN_MODE_L3,
|
2016-09-16 22:59:19 +03:00
|
|
|
IPVLAN_MODE_L3S,
|
2014-11-24 10:07:46 +03:00
|
|
|
IPVLAN_MODE_MAX
|
|
|
|
};
|
|
|
|
|
2017-10-27 01:09:21 +03:00
|
|
|
#define IPVLAN_F_PRIVATE 0x01
|
2017-10-27 01:09:25 +03:00
|
|
|
#define IPVLAN_F_VEPA 0x02
|
2017-10-27 01:09:21 +03:00
|
|
|
|
2022-03-01 08:04:34 +03:00
|
|
|
/* Tunnel RTM header */
|
|
|
|
struct tunnel_msg {
|
|
|
|
__u8 family;
|
2022-03-01 08:04:39 +03:00
|
|
|
__u8 flags;
|
2022-03-01 08:04:34 +03:00
|
|
|
__u16 reserved2;
|
|
|
|
__u32 ifindex;
|
|
|
|
};
|
|
|
|
|
2012-10-13 13:46:48 +04:00
|
|
|
/* VXLAN section */
|
2022-03-01 08:04:39 +03:00
|
|
|
|
|
|
|
/* include statistics in the dump */
|
|
|
|
#define TUNNEL_MSG_FLAG_STATS 0x01
|
|
|
|
|
|
|
|
#define TUNNEL_MSG_VALID_USER_FLAGS TUNNEL_MSG_FLAG_STATS
|
|
|
|
|
|
|
|
/* Embedded inside VXLAN_VNIFILTER_ENTRY_STATS */
|
|
|
|
enum {
|
|
|
|
VNIFILTER_ENTRY_STATS_UNSPEC,
|
|
|
|
VNIFILTER_ENTRY_STATS_RX_BYTES,
|
|
|
|
VNIFILTER_ENTRY_STATS_RX_PKTS,
|
|
|
|
VNIFILTER_ENTRY_STATS_RX_DROPS,
|
|
|
|
VNIFILTER_ENTRY_STATS_RX_ERRORS,
|
|
|
|
VNIFILTER_ENTRY_STATS_TX_BYTES,
|
|
|
|
VNIFILTER_ENTRY_STATS_TX_PKTS,
|
|
|
|
VNIFILTER_ENTRY_STATS_TX_DROPS,
|
|
|
|
VNIFILTER_ENTRY_STATS_TX_ERRORS,
|
|
|
|
VNIFILTER_ENTRY_STATS_PAD,
|
|
|
|
__VNIFILTER_ENTRY_STATS_MAX
|
|
|
|
};
|
|
|
|
#define VNIFILTER_ENTRY_STATS_MAX (__VNIFILTER_ENTRY_STATS_MAX - 1)
|
|
|
|
|
2022-03-01 08:04:34 +03:00
|
|
|
enum {
|
|
|
|
VXLAN_VNIFILTER_ENTRY_UNSPEC,
|
|
|
|
VXLAN_VNIFILTER_ENTRY_START,
|
|
|
|
VXLAN_VNIFILTER_ENTRY_END,
|
|
|
|
VXLAN_VNIFILTER_ENTRY_GROUP,
|
|
|
|
VXLAN_VNIFILTER_ENTRY_GROUP6,
|
2022-03-01 08:04:39 +03:00
|
|
|
VXLAN_VNIFILTER_ENTRY_STATS,
|
2022-03-01 08:04:34 +03:00
|
|
|
__VXLAN_VNIFILTER_ENTRY_MAX
|
|
|
|
};
|
|
|
|
#define VXLAN_VNIFILTER_ENTRY_MAX (__VXLAN_VNIFILTER_ENTRY_MAX - 1)
|
|
|
|
|
|
|
|
enum {
|
|
|
|
VXLAN_VNIFILTER_UNSPEC,
|
|
|
|
VXLAN_VNIFILTER_ENTRY,
|
|
|
|
__VXLAN_VNIFILTER_MAX
|
|
|
|
};
|
|
|
|
#define VXLAN_VNIFILTER_MAX (__VXLAN_VNIFILTER_MAX - 1)
|
|
|
|
|
2012-10-13 13:46:48 +04:00
|
|
|
enum {
|
|
|
|
IFLA_VXLAN_UNSPEC,
|
|
|
|
IFLA_VXLAN_ID,
|
2013-04-27 15:31:55 +04:00
|
|
|
IFLA_VXLAN_GROUP, /* group or remote address */
|
2012-10-13 13:46:48 +04:00
|
|
|
IFLA_VXLAN_LINK,
|
|
|
|
IFLA_VXLAN_LOCAL,
|
|
|
|
IFLA_VXLAN_TTL,
|
|
|
|
IFLA_VXLAN_TOS,
|
|
|
|
IFLA_VXLAN_LEARNING,
|
|
|
|
IFLA_VXLAN_AGEING,
|
|
|
|
IFLA_VXLAN_LIMIT,
|
2013-04-27 15:31:57 +04:00
|
|
|
IFLA_VXLAN_PORT_RANGE, /* source port */
|
2012-11-20 06:50:14 +04:00
|
|
|
IFLA_VXLAN_PROXY,
|
|
|
|
IFLA_VXLAN_RSC,
|
|
|
|
IFLA_VXLAN_L2MISS,
|
|
|
|
IFLA_VXLAN_L3MISS,
|
2013-04-27 15:31:57 +04:00
|
|
|
IFLA_VXLAN_PORT, /* destination port */
|
2013-08-31 09:44:33 +04:00
|
|
|
IFLA_VXLAN_GROUP6,
|
|
|
|
IFLA_VXLAN_LOCAL6,
|
2014-06-05 04:20:29 +04:00
|
|
|
IFLA_VXLAN_UDP_CSUM,
|
|
|
|
IFLA_VXLAN_UDP_ZERO_CSUM6_TX,
|
|
|
|
IFLA_VXLAN_UDP_ZERO_CSUM6_RX,
|
2015-01-13 04:00:38 +03:00
|
|
|
IFLA_VXLAN_REMCSUM_TX,
|
|
|
|
IFLA_VXLAN_REMCSUM_RX,
|
vxlan: Group Policy extension
Implements supports for the Group Policy VXLAN extension [0] to provide
a lightweight and simple security label mechanism across network peers
based on VXLAN. The security context and associated metadata is mapped
to/from skb->mark. This allows further mapping to a SELinux context
using SECMARK, to implement ACLs directly with nftables, iptables, OVS,
tc, etc.
The group membership is defined by the lower 16 bits of skb->mark, the
upper 16 bits are used for flags.
SELinux allows to manage label to secure local resources. However,
distributed applications require ACLs to implemented across hosts. This
is typically achieved by matching on L2-L4 fields to identify the
original sending host and process on the receiver. On top of that,
netlabel and specifically CIPSO [1] allow to map security contexts to
universal labels. However, netlabel and CIPSO are relatively complex.
This patch provides a lightweight alternative for overlay network
environments with a trusted underlay. No additional control protocol
is required.
Host 1: Host 2:
Group A Group B Group B Group A
+-----+ +-------------+ +-------+ +-----+
| lxc | | SELinux CTX | | httpd | | VM |
+--+--+ +--+----------+ +---+---+ +--+--+
\---+---/ \----+---/
| |
+---+---+ +---+---+
| vxlan | | vxlan |
+---+---+ +---+---+
+------------------------------+
Backwards compatibility:
A VXLAN-GBP socket can receive standard VXLAN frames and will assign
the default group 0x0000 to such frames. A Linux VXLAN socket will
drop VXLAN-GBP frames. The extension is therefore disabled by default
and needs to be specifically enabled:
ip link add [...] type vxlan [...] gbp
In a mixed environment with VXLAN and VXLAN-GBP sockets, the GBP socket
must run on a separate port number.
Examples:
iptables:
host1# iptables -I OUTPUT -m owner --uid-owner 101 -j MARK --set-mark 0x200
host2# iptables -I INPUT -m mark --mark 0x200 -j DROP
OVS:
# ovs-ofctl add-flow br0 'in_port=1,actions=load:0x200->NXM_NX_TUN_GBP_ID[],NORMAL'
# ovs-ofctl add-flow br0 'in_port=2,tun_gbp_id=0x200,actions=drop'
[0] https://tools.ietf.org/html/draft-smith-vxlan-group-policy
[1] http://lwn.net/Articles/204905/
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-15 05:53:55 +03:00
|
|
|
IFLA_VXLAN_GBP,
|
2015-02-11 03:30:32 +03:00
|
|
|
IFLA_VXLAN_REMCSUM_NOPARTIAL,
|
2015-07-31 06:10:22 +03:00
|
|
|
IFLA_VXLAN_COLLECT_METADATA,
|
2016-03-09 05:00:03 +03:00
|
|
|
IFLA_VXLAN_LABEL,
|
vxlan: implement GPE
Implement VXLAN-GPE. Only COLLECT_METADATA is supported for now (it is
possible to support static configuration, too, if there is demand for it).
The GPE header parsing has to be moved before iptunnel_pull_header, as we
need to know the protocol.
v2: Removed what was called "L2 mode" in v1 of the patchset. Only "L3 mode"
(now called "raw mode") is added by this patch. This mode does not allow
Ethernet header to be encapsulated in VXLAN-GPE when using ip route to
specify the encapsulation, IP header is encapsulated instead. The patch
does support Ethernet to be encapsulated, though, using ETH_P_TEB in
skb->protocol. This will be utilized by other COLLECT_METADATA users
(openvswitch in particular).
If there is ever demand for Ethernet encapsulation with VXLAN-GPE using
ip route, it's easy to add a new flag switching the interface to
"Ethernet mode" (called "L2 mode" in v1 of this patchset). For now,
leave this out, it seems we don't need it.
Disallowed more flag combinations, especially RCO with GPE.
Added comment explaining that GBP and GPE cannot be set together.
Signed-off-by: Jiri Benc <jbenc@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-04-05 15:47:13 +03:00
|
|
|
IFLA_VXLAN_GPE,
|
2018-04-17 09:11:28 +03:00
|
|
|
IFLA_VXLAN_TTL_INHERIT,
|
vxlan: Allow configuration of DF behaviour
Allow users to set the IPv4 DF bit in outgoing packets, or to inherit its
value from the IPv4 inner header. If the encapsulated protocol is IPv6 and
DF is configured to be inherited, always set it.
For IPv4, inheriting DF from the inner header was probably intended from
the very beginning judging by the comment to vxlan_xmit(), but it wasn't
actually implemented -- also because it would have done more harm than
good, without handling for ICMP Fragmentation Needed messages.
According to RFC 7348, "Path MTU discovery MAY be used". An expired RFC
draft, draft-saum-nvo3-pmtud-over-vxlan-05, whose purpose was to describe
PMTUD implementation, says that "is a MUST that Vxlan gateways [...]
SHOULD set the DF-bit [...]", whatever that means.
Given this background, the only sane option is probably to let the user
decide, and keep the current behaviour as default.
This only applies to non-lwt tunnels: if an external control plane is
used, tunnel key will still control the DF flag.
v2:
- DF behaviour configuration only applies for non-lwt tunnels, move DF
setting to if (!info) block in vxlan_xmit_one() (Stephen Hemminger)
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-11-08 14:19:16 +03:00
|
|
|
IFLA_VXLAN_DF,
|
2022-03-01 08:04:34 +03:00
|
|
|
IFLA_VXLAN_VNIFILTER, /* only applicable with COLLECT_METADATA mode */
|
2012-10-13 13:46:48 +04:00
|
|
|
__IFLA_VXLAN_MAX
|
|
|
|
};
|
|
|
|
#define IFLA_VXLAN_MAX (__IFLA_VXLAN_MAX - 1)
|
|
|
|
|
|
|
|
struct ifla_vxlan_port_range {
|
|
|
|
__be16 low;
|
|
|
|
__be16 high;
|
|
|
|
};
|
|
|
|
|
vxlan: Allow configuration of DF behaviour
Allow users to set the IPv4 DF bit in outgoing packets, or to inherit its
value from the IPv4 inner header. If the encapsulated protocol is IPv6 and
DF is configured to be inherited, always set it.
For IPv4, inheriting DF from the inner header was probably intended from
the very beginning judging by the comment to vxlan_xmit(), but it wasn't
actually implemented -- also because it would have done more harm than
good, without handling for ICMP Fragmentation Needed messages.
According to RFC 7348, "Path MTU discovery MAY be used". An expired RFC
draft, draft-saum-nvo3-pmtud-over-vxlan-05, whose purpose was to describe
PMTUD implementation, says that "is a MUST that Vxlan gateways [...]
SHOULD set the DF-bit [...]", whatever that means.
Given this background, the only sane option is probably to let the user
decide, and keep the current behaviour as default.
This only applies to non-lwt tunnels: if an external control plane is
used, tunnel key will still control the DF flag.
v2:
- DF behaviour configuration only applies for non-lwt tunnels, move DF
setting to if (!info) block in vxlan_xmit_one() (Stephen Hemminger)
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-11-08 14:19:16 +03:00
|
|
|
enum ifla_vxlan_df {
|
|
|
|
VXLAN_DF_UNSET = 0,
|
|
|
|
VXLAN_DF_SET,
|
|
|
|
VXLAN_DF_INHERIT,
|
|
|
|
__VXLAN_DF_END,
|
|
|
|
VXLAN_DF_MAX = __VXLAN_DF_END - 1,
|
|
|
|
};
|
|
|
|
|
2015-05-13 19:57:30 +03:00
|
|
|
/* GENEVE section */
|
|
|
|
enum {
|
|
|
|
IFLA_GENEVE_UNSPEC,
|
|
|
|
IFLA_GENEVE_ID,
|
|
|
|
IFLA_GENEVE_REMOTE,
|
2015-06-01 22:51:34 +03:00
|
|
|
IFLA_GENEVE_TTL,
|
2015-06-01 22:51:35 +03:00
|
|
|
IFLA_GENEVE_TOS,
|
2015-08-27 09:46:51 +03:00
|
|
|
IFLA_GENEVE_PORT, /* destination port */
|
2015-08-27 09:46:52 +03:00
|
|
|
IFLA_GENEVE_COLLECT_METADATA,
|
2015-10-27 00:01:44 +03:00
|
|
|
IFLA_GENEVE_REMOTE6,
|
2015-12-10 23:37:45 +03:00
|
|
|
IFLA_GENEVE_UDP_CSUM,
|
|
|
|
IFLA_GENEVE_UDP_ZERO_CSUM6_TX,
|
|
|
|
IFLA_GENEVE_UDP_ZERO_CSUM6_RX,
|
2016-03-09 05:00:04 +03:00
|
|
|
IFLA_GENEVE_LABEL,
|
2018-09-12 05:04:21 +03:00
|
|
|
IFLA_GENEVE_TTL_INHERIT,
|
2018-11-08 14:19:19 +03:00
|
|
|
IFLA_GENEVE_DF,
|
2022-03-16 09:15:57 +03:00
|
|
|
IFLA_GENEVE_INNER_PROTO_INHERIT,
|
2015-05-13 19:57:30 +03:00
|
|
|
__IFLA_GENEVE_MAX
|
|
|
|
};
|
|
|
|
#define IFLA_GENEVE_MAX (__IFLA_GENEVE_MAX - 1)
|
|
|
|
|
2018-11-08 14:19:19 +03:00
|
|
|
enum ifla_geneve_df {
|
|
|
|
GENEVE_DF_UNSET = 0,
|
|
|
|
GENEVE_DF_SET,
|
|
|
|
GENEVE_DF_INHERIT,
|
|
|
|
__GENEVE_DF_END,
|
|
|
|
GENEVE_DF_MAX = __GENEVE_DF_END - 1,
|
|
|
|
};
|
|
|
|
|
2020-02-24 08:27:50 +03:00
|
|
|
/* Bareudp section */
|
|
|
|
enum {
|
|
|
|
IFLA_BAREUDP_UNSPEC,
|
|
|
|
IFLA_BAREUDP_PORT,
|
|
|
|
IFLA_BAREUDP_ETHERTYPE,
|
|
|
|
IFLA_BAREUDP_SRCPORT_MIN,
|
2020-02-24 08:28:35 +03:00
|
|
|
IFLA_BAREUDP_MULTIPROTO_MODE,
|
2020-02-24 08:27:50 +03:00
|
|
|
__IFLA_BAREUDP_MAX
|
|
|
|
};
|
|
|
|
|
|
|
|
#define IFLA_BAREUDP_MAX (__IFLA_BAREUDP_MAX - 1)
|
|
|
|
|
2016-04-28 18:55:30 +03:00
|
|
|
/* PPP section */
|
|
|
|
enum {
|
|
|
|
IFLA_PPP_UNSPEC,
|
|
|
|
IFLA_PPP_DEV_FD,
|
|
|
|
__IFLA_PPP_MAX
|
|
|
|
};
|
|
|
|
#define IFLA_PPP_MAX (__IFLA_PPP_MAX - 1)
|
|
|
|
|
2016-05-09 01:55:48 +03:00
|
|
|
/* GTP section */
|
2017-03-25 01:23:21 +03:00
|
|
|
|
|
|
|
enum ifla_gtp_role {
|
|
|
|
GTP_ROLE_GGSN = 0,
|
|
|
|
GTP_ROLE_SGSN,
|
|
|
|
};
|
|
|
|
|
2016-05-09 01:55:48 +03:00
|
|
|
enum {
|
|
|
|
IFLA_GTP_UNSPEC,
|
|
|
|
IFLA_GTP_FD0,
|
|
|
|
IFLA_GTP_FD1,
|
|
|
|
IFLA_GTP_PDP_HASHSIZE,
|
2017-03-25 01:23:21 +03:00
|
|
|
IFLA_GTP_ROLE,
|
2022-03-04 19:40:42 +03:00
|
|
|
IFLA_GTP_CREATE_SOCKETS,
|
2022-03-04 19:40:43 +03:00
|
|
|
IFLA_GTP_RESTART_COUNT,
|
2016-05-09 01:55:48 +03:00
|
|
|
__IFLA_GTP_MAX,
|
|
|
|
};
|
|
|
|
#define IFLA_GTP_MAX (__IFLA_GTP_MAX - 1)
|
|
|
|
|
2013-10-18 19:43:38 +04:00
|
|
|
/* Bonding section */
|
|
|
|
|
|
|
|
enum {
|
|
|
|
IFLA_BOND_UNSPEC,
|
|
|
|
IFLA_BOND_MODE,
|
2013-10-18 19:43:39 +04:00
|
|
|
IFLA_BOND_ACTIVE_SLAVE,
|
2013-12-13 02:09:55 +04:00
|
|
|
IFLA_BOND_MIIMON,
|
2013-12-13 02:10:02 +04:00
|
|
|
IFLA_BOND_UPDELAY,
|
2013-12-13 02:10:09 +04:00
|
|
|
IFLA_BOND_DOWNDELAY,
|
2013-12-13 02:10:16 +04:00
|
|
|
IFLA_BOND_USE_CARRIER,
|
2013-12-13 02:10:24 +04:00
|
|
|
IFLA_BOND_ARP_INTERVAL,
|
2013-12-13 02:10:31 +04:00
|
|
|
IFLA_BOND_ARP_IP_TARGET,
|
2013-12-13 02:10:38 +04:00
|
|
|
IFLA_BOND_ARP_VALIDATE,
|
2013-12-13 02:10:45 +04:00
|
|
|
IFLA_BOND_ARP_ALL_TARGETS,
|
2013-12-16 04:41:51 +04:00
|
|
|
IFLA_BOND_PRIMARY,
|
2013-12-16 04:41:58 +04:00
|
|
|
IFLA_BOND_PRIMARY_RESELECT,
|
2013-12-16 04:42:05 +04:00
|
|
|
IFLA_BOND_FAIL_OVER_MAC,
|
2013-12-16 04:42:12 +04:00
|
|
|
IFLA_BOND_XMIT_HASH_POLICY,
|
2013-12-16 04:42:19 +04:00
|
|
|
IFLA_BOND_RESEND_IGMP,
|
2013-12-18 09:30:09 +04:00
|
|
|
IFLA_BOND_NUM_PEER_NOTIF,
|
2013-12-18 09:30:16 +04:00
|
|
|
IFLA_BOND_ALL_SLAVES_ACTIVE,
|
2013-12-18 09:30:23 +04:00
|
|
|
IFLA_BOND_MIN_LINKS,
|
2013-12-18 09:30:30 +04:00
|
|
|
IFLA_BOND_LP_INTERVAL,
|
2013-12-18 09:30:37 +04:00
|
|
|
IFLA_BOND_PACKETS_PER_SLAVE,
|
2014-01-04 02:18:41 +04:00
|
|
|
IFLA_BOND_AD_LACP_RATE,
|
2014-01-04 02:18:49 +04:00
|
|
|
IFLA_BOND_AD_SELECT,
|
2014-01-04 02:18:56 +04:00
|
|
|
IFLA_BOND_AD_INFO,
|
2015-05-09 10:01:58 +03:00
|
|
|
IFLA_BOND_AD_ACTOR_SYS_PRIO,
|
|
|
|
IFLA_BOND_AD_USER_PORT_KEY,
|
|
|
|
IFLA_BOND_AD_ACTOR_SYSTEM,
|
2015-07-31 17:49:43 +03:00
|
|
|
IFLA_BOND_TLB_DYNAMIC_LB,
|
bonding: add an option to specify a delay between peer notifications
Currently, gratuitous ARP/ND packets are sent every `miimon'
milliseconds. This commit allows a user to specify a custom delay
through a new option, `peer_notif_delay'.
Like for `updelay' and `downdelay', this delay should be a multiple of
`miimon' to avoid managing an additional work queue. The configuration
logic is copied from `updelay' and `downdelay'. However, the default
value cannot be set using a module parameter: Netlink or sysfs should
be used to configure this feature.
When setting `miimon' to 100 and `peer_notif_delay' to 500, we can
observe the 500 ms delay is respected:
20:30:19.354693 ARP, Request who-has 203.0.113.10 tell 203.0.113.10, length 28
20:30:19.874892 ARP, Request who-has 203.0.113.10 tell 203.0.113.10, length 28
20:30:20.394919 ARP, Request who-has 203.0.113.10 tell 203.0.113.10, length 28
20:30:20.914963 ARP, Request who-has 203.0.113.10 tell 203.0.113.10, length 28
In bond_mii_monitor(), I have tried to keep the lock logic readable.
The change is due to the fact we cannot rely on a notification to
lower the value of `bond->send_peer_notif' as `NETDEV_NOTIFY_PEERS' is
only triggered once every N times, while we need to decrement the
counter each time.
iproute2 also needs to be updated to be able to specify this new
attribute through `ip link'.
Signed-off-by: Vincent Bernat <vincent@bernat.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-07-02 20:43:54 +03:00
|
|
|
IFLA_BOND_PEER_NOTIF_DELAY,
|
2021-08-02 06:02:19 +03:00
|
|
|
IFLA_BOND_AD_LACP_ACTIVE,
|
2021-11-30 07:29:47 +03:00
|
|
|
IFLA_BOND_MISSED_MAX,
|
2022-02-21 08:54:57 +03:00
|
|
|
IFLA_BOND_NS_IP6_TARGET,
|
2013-10-18 19:43:38 +04:00
|
|
|
__IFLA_BOND_MAX,
|
|
|
|
};
|
|
|
|
|
|
|
|
#define IFLA_BOND_MAX (__IFLA_BOND_MAX - 1)
|
|
|
|
|
2014-01-04 02:18:56 +04:00
|
|
|
enum {
|
2014-01-23 19:51:27 +04:00
|
|
|
IFLA_BOND_AD_INFO_UNSPEC,
|
2014-01-04 02:18:56 +04:00
|
|
|
IFLA_BOND_AD_INFO_AGGREGATOR,
|
|
|
|
IFLA_BOND_AD_INFO_NUM_PORTS,
|
|
|
|
IFLA_BOND_AD_INFO_ACTOR_KEY,
|
|
|
|
IFLA_BOND_AD_INFO_PARTNER_KEY,
|
|
|
|
IFLA_BOND_AD_INFO_PARTNER_MAC,
|
|
|
|
__IFLA_BOND_AD_INFO_MAX,
|
|
|
|
};
|
|
|
|
|
|
|
|
#define IFLA_BOND_AD_INFO_MAX (__IFLA_BOND_AD_INFO_MAX - 1)
|
|
|
|
|
2014-01-17 10:57:56 +04:00
|
|
|
enum {
|
2014-01-22 12:05:54 +04:00
|
|
|
IFLA_BOND_SLAVE_UNSPEC,
|
|
|
|
IFLA_BOND_SLAVE_STATE,
|
|
|
|
IFLA_BOND_SLAVE_MII_STATUS,
|
|
|
|
IFLA_BOND_SLAVE_LINK_FAILURE_COUNT,
|
|
|
|
IFLA_BOND_SLAVE_PERM_HWADDR,
|
|
|
|
IFLA_BOND_SLAVE_QUEUE_ID,
|
|
|
|
IFLA_BOND_SLAVE_AD_AGGREGATOR_ID,
|
2015-06-14 16:36:34 +03:00
|
|
|
IFLA_BOND_SLAVE_AD_ACTOR_OPER_PORT_STATE,
|
2015-06-14 16:36:35 +03:00
|
|
|
IFLA_BOND_SLAVE_AD_PARTNER_OPER_PORT_STATE,
|
2014-01-22 12:05:54 +04:00
|
|
|
__IFLA_BOND_SLAVE_MAX,
|
2014-01-17 10:57:56 +04:00
|
|
|
};
|
|
|
|
|
2014-01-22 12:05:54 +04:00
|
|
|
#define IFLA_BOND_SLAVE_MAX (__IFLA_BOND_SLAVE_MAX - 1)
|
2014-01-17 10:57:56 +04:00
|
|
|
|
2012-10-13 13:46:48 +04:00
|
|
|
/* SR-IOV virtual function management section */
|
|
|
|
|
|
|
|
enum {
|
|
|
|
IFLA_VF_INFO_UNSPEC,
|
|
|
|
IFLA_VF_INFO,
|
|
|
|
__IFLA_VF_INFO_MAX,
|
|
|
|
};
|
|
|
|
|
|
|
|
#define IFLA_VF_INFO_MAX (__IFLA_VF_INFO_MAX - 1)
|
|
|
|
|
|
|
|
enum {
|
|
|
|
IFLA_VF_UNSPEC,
|
|
|
|
IFLA_VF_MAC, /* Hardware queue specific attributes */
|
2016-09-22 12:11:15 +03:00
|
|
|
IFLA_VF_VLAN, /* VLAN ID and QoS */
|
net-next:v4: Add support to configure SR-IOV VF minimum and maximum Tx rate through ip tool.
o min_tx_rate puts lower limit on the VF bandwidth. VF is guaranteed
to have a bandwidth of at least this value.
max_tx_rate puts cap on the VF bandwidth. VF can have a bandwidth
of up to this value.
o A new handler set_vf_rate for attr IFLA_VF_RATE has been introduced
which takes 4 arguments:
netdev, VF number, min_tx_rate, max_tx_rate
o ndo_set_vf_rate replaces ndo_set_vf_tx_rate handler.
o Drivers that currently implement ndo_set_vf_tx_rate should now call
ndo_set_vf_rate instead and reject attempt to set a minimum bandwidth
greater than 0 for IFLA_VF_TX_RATE when IFLA_VF_RATE is not yet
implemented by driver.
o If user enters only one of either min_tx_rate or max_tx_rate, then,
userland should read back the other value from driver and set both
for IFLA_VF_RATE.
Drivers that have not yet implemented IFLA_VF_RATE should always
return min_tx_rate as 0 when read from ip tool.
o If both IFLA_VF_TX_RATE and IFLA_VF_RATE options are specified, then
IFLA_VF_RATE should override.
o Idea is to have consistent display of rate values to user.
o Usage example: -
./ip link set p4p1 vf 0 rate 900
./ip link show p4p1
32: p4p1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT qlen 1000
link/ether 00:0e:1e:08:b0:f0 brd ff:ff:ff:ff:ff:ff
vf 0 MAC 3e:a0:ca:bd:ae:5a, tx rate 900 (Mbps), max_tx_rate 900Mbps
vf 1 MAC f6:c6:7c:3f:3d:6c
vf 2 MAC 56:32:43:98:d7:71
vf 3 MAC d6:be:c3:b5:85:ff
vf 4 MAC ee:a9:9a:1e:19:14
vf 5 MAC 4a:d0:4c:07:52:18
vf 6 MAC 3a:76:44:93:62:f9
vf 7 MAC 82:e9:e7:e3:15:1a
./ip link set p4p1 vf 0 max_tx_rate 300 min_tx_rate 200
./ip link show p4p1
32: p4p1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT qlen 1000
link/ether 00:0e:1e:08:b0:f0 brd ff:ff:ff:ff:ff:ff
vf 0 MAC 3e:a0:ca:bd:ae:5a, tx rate 300 (Mbps), max_tx_rate 300Mbps,
min_tx_rate 200Mbps
vf 1 MAC f6:c6:7c:3f:3d:6c
vf 2 MAC 56:32:43:98:d7:71
vf 3 MAC d6:be:c3:b5:85:ff
vf 4 MAC ee:a9:9a:1e:19:14
vf 5 MAC 4a:d0:4c:07:52:18
vf 6 MAC 3a:76:44:93:62:f9
vf 7 MAC 82:e9:e7:e3:15:1a
./ip link set p4p1 vf 0 max_tx_rate 600 rate 300
./ip link show p4p1
32: p4p1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT qlen 1000
link/ether 00:0e:1e:08:b0:f brd ff:ff:ff:ff:ff:ff
vf 0 MAC 3e:a0:ca:bd:ae:5, tx rate 600 (Mbps), max_tx_rate 600Mbps,
min_tx_rate 200Mbps
vf 1 MAC f6:c6:7c:3f:3d:6c
vf 2 MAC 56:32:43:98:d7:71
vf 3 MAC d6:be:c3:b5:85:ff
vf 4 MAC ee:a9:9a:1e:19:14
vf 5 MAC 4a:d0:4c:07:52:18
vf 6 MAC 3a:76:44:93:62:f9
vf 7 MAC 82:e9:e7:e3:15:1a
Signed-off-by: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-22 17:59:05 +04:00
|
|
|
IFLA_VF_TX_RATE, /* Max TX Bandwidth Allocation */
|
2012-10-13 13:46:48 +04:00
|
|
|
IFLA_VF_SPOOFCHK, /* Spoof Checking on/off switch */
|
2013-06-13 14:19:10 +04:00
|
|
|
IFLA_VF_LINK_STATE, /* link state enable/disable/auto switch */
|
net-next:v4: Add support to configure SR-IOV VF minimum and maximum Tx rate through ip tool.
o min_tx_rate puts lower limit on the VF bandwidth. VF is guaranteed
to have a bandwidth of at least this value.
max_tx_rate puts cap on the VF bandwidth. VF can have a bandwidth
of up to this value.
o A new handler set_vf_rate for attr IFLA_VF_RATE has been introduced
which takes 4 arguments:
netdev, VF number, min_tx_rate, max_tx_rate
o ndo_set_vf_rate replaces ndo_set_vf_tx_rate handler.
o Drivers that currently implement ndo_set_vf_tx_rate should now call
ndo_set_vf_rate instead and reject attempt to set a minimum bandwidth
greater than 0 for IFLA_VF_TX_RATE when IFLA_VF_RATE is not yet
implemented by driver.
o If user enters only one of either min_tx_rate or max_tx_rate, then,
userland should read back the other value from driver and set both
for IFLA_VF_RATE.
Drivers that have not yet implemented IFLA_VF_RATE should always
return min_tx_rate as 0 when read from ip tool.
o If both IFLA_VF_TX_RATE and IFLA_VF_RATE options are specified, then
IFLA_VF_RATE should override.
o Idea is to have consistent display of rate values to user.
o Usage example: -
./ip link set p4p1 vf 0 rate 900
./ip link show p4p1
32: p4p1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT qlen 1000
link/ether 00:0e:1e:08:b0:f0 brd ff:ff:ff:ff:ff:ff
vf 0 MAC 3e:a0:ca:bd:ae:5a, tx rate 900 (Mbps), max_tx_rate 900Mbps
vf 1 MAC f6:c6:7c:3f:3d:6c
vf 2 MAC 56:32:43:98:d7:71
vf 3 MAC d6:be:c3:b5:85:ff
vf 4 MAC ee:a9:9a:1e:19:14
vf 5 MAC 4a:d0:4c:07:52:18
vf 6 MAC 3a:76:44:93:62:f9
vf 7 MAC 82:e9:e7:e3:15:1a
./ip link set p4p1 vf 0 max_tx_rate 300 min_tx_rate 200
./ip link show p4p1
32: p4p1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT qlen 1000
link/ether 00:0e:1e:08:b0:f0 brd ff:ff:ff:ff:ff:ff
vf 0 MAC 3e:a0:ca:bd:ae:5a, tx rate 300 (Mbps), max_tx_rate 300Mbps,
min_tx_rate 200Mbps
vf 1 MAC f6:c6:7c:3f:3d:6c
vf 2 MAC 56:32:43:98:d7:71
vf 3 MAC d6:be:c3:b5:85:ff
vf 4 MAC ee:a9:9a:1e:19:14
vf 5 MAC 4a:d0:4c:07:52:18
vf 6 MAC 3a:76:44:93:62:f9
vf 7 MAC 82:e9:e7:e3:15:1a
./ip link set p4p1 vf 0 max_tx_rate 600 rate 300
./ip link show p4p1
32: p4p1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT qlen 1000
link/ether 00:0e:1e:08:b0:f brd ff:ff:ff:ff:ff:ff
vf 0 MAC 3e:a0:ca:bd:ae:5, tx rate 600 (Mbps), max_tx_rate 600Mbps,
min_tx_rate 200Mbps
vf 1 MAC f6:c6:7c:3f:3d:6c
vf 2 MAC 56:32:43:98:d7:71
vf 3 MAC d6:be:c3:b5:85:ff
vf 4 MAC ee:a9:9a:1e:19:14
vf 5 MAC 4a:d0:4c:07:52:18
vf 6 MAC 3a:76:44:93:62:f9
vf 7 MAC 82:e9:e7:e3:15:1a
Signed-off-by: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-22 17:59:05 +04:00
|
|
|
IFLA_VF_RATE, /* Min and Max TX Bandwidth Allocation */
|
2015-03-30 21:35:23 +03:00
|
|
|
IFLA_VF_RSS_QUERY_EN, /* RSS Redirection Table and Hash Key query
|
|
|
|
* on/off switch
|
|
|
|
*/
|
2015-06-15 17:59:07 +03:00
|
|
|
IFLA_VF_STATS, /* network device statistics */
|
2015-08-28 09:57:55 +03:00
|
|
|
IFLA_VF_TRUST, /* Trust VF */
|
2016-03-11 23:58:34 +03:00
|
|
|
IFLA_VF_IB_NODE_GUID, /* VF Infiniband node GUID */
|
|
|
|
IFLA_VF_IB_PORT_GUID, /* VF Infiniband port GUID */
|
2016-09-22 12:11:15 +03:00
|
|
|
IFLA_VF_VLAN_LIST, /* nested list of vlans, option for QinQ */
|
ipoib: show VF broadcast address
in IPoIB case we can't see a VF broadcast address for but
can see for PF
Before:
11: ib1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2044 qdisc pfifo_fast
state UP mode DEFAULT group default qlen 256
link/infiniband
80:00:00:66:fe:80:00:00:00:00:00:00:24:8a:07:03:00:a4:3e:7c brd
00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
vf 0 MAC 14:80:00:00:66:fe, spoof checking off, link-state disable,
trust off, query_rss off
...
After:
11: ib1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2044 qdisc pfifo_fast
state UP mode DEFAULT group default qlen 256
link/infiniband
80:00:00:66:fe:80:00:00:00:00:00:00:24:8a:07:03:00:a4:3e:7c brd
00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
vf 0 link/infiniband
80:00:00:66:fe:80:00:00:00:00:00:00:24:8a:07:03:00:a4:3e:7c brd
00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff, spoof
checking off, link-state disable, trust off, query_rss off
v1->v2: add the IFLA_VF_BROADCAST constant
v2->v3: put IFLA_VF_BROADCAST at the end
to avoid KABI breakage and set NLA_REJECT
dev_setlink
Signed-off-by: Denis Kirjanov <kda@linux-powerpc.org>
Acked-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-17 11:53:41 +03:00
|
|
|
IFLA_VF_BROADCAST, /* VF broadcast */
|
2012-10-13 13:46:48 +04:00
|
|
|
__IFLA_VF_MAX,
|
|
|
|
};
|
|
|
|
|
|
|
|
#define IFLA_VF_MAX (__IFLA_VF_MAX - 1)
|
|
|
|
|
|
|
|
struct ifla_vf_mac {
|
|
|
|
__u32 vf;
|
|
|
|
__u8 mac[32]; /* MAX_ADDR_LEN */
|
|
|
|
};
|
|
|
|
|
ipoib: show VF broadcast address
in IPoIB case we can't see a VF broadcast address for but
can see for PF
Before:
11: ib1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2044 qdisc pfifo_fast
state UP mode DEFAULT group default qlen 256
link/infiniband
80:00:00:66:fe:80:00:00:00:00:00:00:24:8a:07:03:00:a4:3e:7c brd
00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
vf 0 MAC 14:80:00:00:66:fe, spoof checking off, link-state disable,
trust off, query_rss off
...
After:
11: ib1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2044 qdisc pfifo_fast
state UP mode DEFAULT group default qlen 256
link/infiniband
80:00:00:66:fe:80:00:00:00:00:00:00:24:8a:07:03:00:a4:3e:7c brd
00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
vf 0 link/infiniband
80:00:00:66:fe:80:00:00:00:00:00:00:24:8a:07:03:00:a4:3e:7c brd
00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff, spoof
checking off, link-state disable, trust off, query_rss off
v1->v2: add the IFLA_VF_BROADCAST constant
v2->v3: put IFLA_VF_BROADCAST at the end
to avoid KABI breakage and set NLA_REJECT
dev_setlink
Signed-off-by: Denis Kirjanov <kda@linux-powerpc.org>
Acked-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-17 11:53:41 +03:00
|
|
|
struct ifla_vf_broadcast {
|
|
|
|
__u8 broadcast[32];
|
|
|
|
};
|
|
|
|
|
2012-10-13 13:46:48 +04:00
|
|
|
struct ifla_vf_vlan {
|
|
|
|
__u32 vf;
|
|
|
|
__u32 vlan; /* 0 - 4095, 0 disables VLAN filter */
|
|
|
|
__u32 qos;
|
|
|
|
};
|
|
|
|
|
2016-09-22 12:11:15 +03:00
|
|
|
enum {
|
|
|
|
IFLA_VF_VLAN_INFO_UNSPEC,
|
|
|
|
IFLA_VF_VLAN_INFO, /* VLAN ID, QoS and VLAN protocol */
|
|
|
|
__IFLA_VF_VLAN_INFO_MAX,
|
|
|
|
};
|
|
|
|
|
|
|
|
#define IFLA_VF_VLAN_INFO_MAX (__IFLA_VF_VLAN_INFO_MAX - 1)
|
|
|
|
#define MAX_VLAN_LIST_LEN 1
|
|
|
|
|
|
|
|
struct ifla_vf_vlan_info {
|
|
|
|
__u32 vf;
|
|
|
|
__u32 vlan; /* 0 - 4095, 0 disables VLAN filter */
|
|
|
|
__u32 qos;
|
|
|
|
__be16 vlan_proto; /* VLAN protocol either 802.1Q or 802.1ad */
|
|
|
|
};
|
|
|
|
|
2012-10-13 13:46:48 +04:00
|
|
|
struct ifla_vf_tx_rate {
|
|
|
|
__u32 vf;
|
|
|
|
__u32 rate; /* Max TX bandwidth in Mbps, 0 disables throttling */
|
|
|
|
};
|
|
|
|
|
net-next:v4: Add support to configure SR-IOV VF minimum and maximum Tx rate through ip tool.
o min_tx_rate puts lower limit on the VF bandwidth. VF is guaranteed
to have a bandwidth of at least this value.
max_tx_rate puts cap on the VF bandwidth. VF can have a bandwidth
of up to this value.
o A new handler set_vf_rate for attr IFLA_VF_RATE has been introduced
which takes 4 arguments:
netdev, VF number, min_tx_rate, max_tx_rate
o ndo_set_vf_rate replaces ndo_set_vf_tx_rate handler.
o Drivers that currently implement ndo_set_vf_tx_rate should now call
ndo_set_vf_rate instead and reject attempt to set a minimum bandwidth
greater than 0 for IFLA_VF_TX_RATE when IFLA_VF_RATE is not yet
implemented by driver.
o If user enters only one of either min_tx_rate or max_tx_rate, then,
userland should read back the other value from driver and set both
for IFLA_VF_RATE.
Drivers that have not yet implemented IFLA_VF_RATE should always
return min_tx_rate as 0 when read from ip tool.
o If both IFLA_VF_TX_RATE and IFLA_VF_RATE options are specified, then
IFLA_VF_RATE should override.
o Idea is to have consistent display of rate values to user.
o Usage example: -
./ip link set p4p1 vf 0 rate 900
./ip link show p4p1
32: p4p1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT qlen 1000
link/ether 00:0e:1e:08:b0:f0 brd ff:ff:ff:ff:ff:ff
vf 0 MAC 3e:a0:ca:bd:ae:5a, tx rate 900 (Mbps), max_tx_rate 900Mbps
vf 1 MAC f6:c6:7c:3f:3d:6c
vf 2 MAC 56:32:43:98:d7:71
vf 3 MAC d6:be:c3:b5:85:ff
vf 4 MAC ee:a9:9a:1e:19:14
vf 5 MAC 4a:d0:4c:07:52:18
vf 6 MAC 3a:76:44:93:62:f9
vf 7 MAC 82:e9:e7:e3:15:1a
./ip link set p4p1 vf 0 max_tx_rate 300 min_tx_rate 200
./ip link show p4p1
32: p4p1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT qlen 1000
link/ether 00:0e:1e:08:b0:f0 brd ff:ff:ff:ff:ff:ff
vf 0 MAC 3e:a0:ca:bd:ae:5a, tx rate 300 (Mbps), max_tx_rate 300Mbps,
min_tx_rate 200Mbps
vf 1 MAC f6:c6:7c:3f:3d:6c
vf 2 MAC 56:32:43:98:d7:71
vf 3 MAC d6:be:c3:b5:85:ff
vf 4 MAC ee:a9:9a:1e:19:14
vf 5 MAC 4a:d0:4c:07:52:18
vf 6 MAC 3a:76:44:93:62:f9
vf 7 MAC 82:e9:e7:e3:15:1a
./ip link set p4p1 vf 0 max_tx_rate 600 rate 300
./ip link show p4p1
32: p4p1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT qlen 1000
link/ether 00:0e:1e:08:b0:f brd ff:ff:ff:ff:ff:ff
vf 0 MAC 3e:a0:ca:bd:ae:5, tx rate 600 (Mbps), max_tx_rate 600Mbps,
min_tx_rate 200Mbps
vf 1 MAC f6:c6:7c:3f:3d:6c
vf 2 MAC 56:32:43:98:d7:71
vf 3 MAC d6:be:c3:b5:85:ff
vf 4 MAC ee:a9:9a:1e:19:14
vf 5 MAC 4a:d0:4c:07:52:18
vf 6 MAC 3a:76:44:93:62:f9
vf 7 MAC 82:e9:e7:e3:15:1a
Signed-off-by: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-22 17:59:05 +04:00
|
|
|
struct ifla_vf_rate {
|
|
|
|
__u32 vf;
|
|
|
|
__u32 min_tx_rate; /* Min Bandwidth in Mbps */
|
|
|
|
__u32 max_tx_rate; /* Max Bandwidth in Mbps */
|
|
|
|
};
|
|
|
|
|
2012-10-13 13:46:48 +04:00
|
|
|
struct ifla_vf_spoofchk {
|
|
|
|
__u32 vf;
|
|
|
|
__u32 setting;
|
|
|
|
};
|
|
|
|
|
2016-03-11 23:58:34 +03:00
|
|
|
struct ifla_vf_guid {
|
|
|
|
__u32 vf;
|
|
|
|
__u64 guid;
|
|
|
|
};
|
|
|
|
|
2013-06-13 14:19:10 +04:00
|
|
|
enum {
|
|
|
|
IFLA_VF_LINK_STATE_AUTO, /* link state of the uplink */
|
|
|
|
IFLA_VF_LINK_STATE_ENABLE, /* link always up */
|
|
|
|
IFLA_VF_LINK_STATE_DISABLE, /* link always down */
|
|
|
|
__IFLA_VF_LINK_STATE_MAX,
|
|
|
|
};
|
|
|
|
|
|
|
|
struct ifla_vf_link_state {
|
|
|
|
__u32 vf;
|
|
|
|
__u32 link_state;
|
|
|
|
};
|
|
|
|
|
2015-03-30 21:35:23 +03:00
|
|
|
struct ifla_vf_rss_query_en {
|
|
|
|
__u32 vf;
|
|
|
|
__u32 setting;
|
|
|
|
};
|
|
|
|
|
2015-06-15 17:59:07 +03:00
|
|
|
enum {
|
|
|
|
IFLA_VF_STATS_RX_PACKETS,
|
|
|
|
IFLA_VF_STATS_TX_PACKETS,
|
|
|
|
IFLA_VF_STATS_RX_BYTES,
|
|
|
|
IFLA_VF_STATS_TX_BYTES,
|
|
|
|
IFLA_VF_STATS_BROADCAST,
|
|
|
|
IFLA_VF_STATS_MULTICAST,
|
2016-04-25 11:25:14 +03:00
|
|
|
IFLA_VF_STATS_PAD,
|
2017-07-17 13:47:07 +03:00
|
|
|
IFLA_VF_STATS_RX_DROPPED,
|
|
|
|
IFLA_VF_STATS_TX_DROPPED,
|
2015-06-15 17:59:07 +03:00
|
|
|
__IFLA_VF_STATS_MAX,
|
|
|
|
};
|
|
|
|
|
|
|
|
#define IFLA_VF_STATS_MAX (__IFLA_VF_STATS_MAX - 1)
|
|
|
|
|
2015-08-28 09:57:55 +03:00
|
|
|
struct ifla_vf_trust {
|
|
|
|
__u32 vf;
|
|
|
|
__u32 setting;
|
|
|
|
};
|
|
|
|
|
2012-10-13 13:46:48 +04:00
|
|
|
/* VF ports management section
|
|
|
|
*
|
|
|
|
* Nested layout of set/get msg is:
|
|
|
|
*
|
|
|
|
* [IFLA_NUM_VF]
|
|
|
|
* [IFLA_VF_PORTS]
|
|
|
|
* [IFLA_VF_PORT]
|
|
|
|
* [IFLA_PORT_*], ...
|
|
|
|
* [IFLA_VF_PORT]
|
|
|
|
* [IFLA_PORT_*], ...
|
|
|
|
* ...
|
|
|
|
* [IFLA_PORT_SELF]
|
|
|
|
* [IFLA_PORT_*], ...
|
|
|
|
*/
|
|
|
|
|
|
|
|
enum {
|
|
|
|
IFLA_VF_PORT_UNSPEC,
|
|
|
|
IFLA_VF_PORT, /* nest */
|
|
|
|
__IFLA_VF_PORT_MAX,
|
|
|
|
};
|
|
|
|
|
|
|
|
#define IFLA_VF_PORT_MAX (__IFLA_VF_PORT_MAX - 1)
|
|
|
|
|
|
|
|
enum {
|
|
|
|
IFLA_PORT_UNSPEC,
|
|
|
|
IFLA_PORT_VF, /* __u32 */
|
|
|
|
IFLA_PORT_PROFILE, /* string */
|
|
|
|
IFLA_PORT_VSI_TYPE, /* 802.1Qbg (pre-)standard VDP */
|
|
|
|
IFLA_PORT_INSTANCE_UUID, /* binary UUID */
|
|
|
|
IFLA_PORT_HOST_UUID, /* binary UUID */
|
|
|
|
IFLA_PORT_REQUEST, /* __u8 */
|
|
|
|
IFLA_PORT_RESPONSE, /* __u16, output only */
|
|
|
|
__IFLA_PORT_MAX,
|
|
|
|
};
|
|
|
|
|
|
|
|
#define IFLA_PORT_MAX (__IFLA_PORT_MAX - 1)
|
|
|
|
|
|
|
|
#define PORT_PROFILE_MAX 40
|
|
|
|
#define PORT_UUID_MAX 16
|
|
|
|
#define PORT_SELF_VF -1
|
|
|
|
|
|
|
|
enum {
|
|
|
|
PORT_REQUEST_PREASSOCIATE = 0,
|
|
|
|
PORT_REQUEST_PREASSOCIATE_RR,
|
|
|
|
PORT_REQUEST_ASSOCIATE,
|
|
|
|
PORT_REQUEST_DISASSOCIATE,
|
|
|
|
};
|
|
|
|
|
|
|
|
enum {
|
|
|
|
PORT_VDP_RESPONSE_SUCCESS = 0,
|
|
|
|
PORT_VDP_RESPONSE_INVALID_FORMAT,
|
|
|
|
PORT_VDP_RESPONSE_INSUFFICIENT_RESOURCES,
|
|
|
|
PORT_VDP_RESPONSE_UNUSED_VTID,
|
|
|
|
PORT_VDP_RESPONSE_VTID_VIOLATION,
|
|
|
|
PORT_VDP_RESPONSE_VTID_VERSION_VIOALTION,
|
|
|
|
PORT_VDP_RESPONSE_OUT_OF_SYNC,
|
|
|
|
/* 0x08-0xFF reserved for future VDP use */
|
|
|
|
PORT_PROFILE_RESPONSE_SUCCESS = 0x100,
|
|
|
|
PORT_PROFILE_RESPONSE_INPROGRESS,
|
|
|
|
PORT_PROFILE_RESPONSE_INVALID,
|
|
|
|
PORT_PROFILE_RESPONSE_BADSTATE,
|
|
|
|
PORT_PROFILE_RESPONSE_INSUFFICIENT_RESOURCES,
|
|
|
|
PORT_PROFILE_RESPONSE_ERROR,
|
|
|
|
};
|
|
|
|
|
|
|
|
struct ifla_port_vsi {
|
|
|
|
__u8 vsi_mgr_id;
|
|
|
|
__u8 vsi_type_id[3];
|
|
|
|
__u8 vsi_type_version;
|
|
|
|
__u8 pad[3];
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
/* IPoIB section */
|
|
|
|
|
|
|
|
enum {
|
|
|
|
IFLA_IPOIB_UNSPEC,
|
|
|
|
IFLA_IPOIB_PKEY,
|
|
|
|
IFLA_IPOIB_MODE,
|
|
|
|
IFLA_IPOIB_UMCAST,
|
|
|
|
__IFLA_IPOIB_MAX
|
|
|
|
};
|
|
|
|
|
|
|
|
enum {
|
|
|
|
IPOIB_MODE_DATAGRAM = 0, /* using unreliable datagram QPs */
|
|
|
|
IPOIB_MODE_CONNECTED = 1, /* using connected QPs */
|
|
|
|
};
|
|
|
|
|
|
|
|
#define IFLA_IPOIB_MAX (__IFLA_IPOIB_MAX - 1)
|
|
|
|
|
2013-10-31 00:10:47 +04:00
|
|
|
|
2020-07-22 17:40:16 +03:00
|
|
|
/* HSR/PRP section, both uses same interface */
|
|
|
|
|
|
|
|
/* Different redundancy protocols for hsr device */
|
|
|
|
enum {
|
|
|
|
HSR_PROTOCOL_HSR,
|
|
|
|
HSR_PROTOCOL_PRP,
|
|
|
|
HSR_PROTOCOL_MAX,
|
|
|
|
};
|
2013-10-31 00:10:47 +04:00
|
|
|
|
|
|
|
enum {
|
|
|
|
IFLA_HSR_UNSPEC,
|
|
|
|
IFLA_HSR_SLAVE1,
|
|
|
|
IFLA_HSR_SLAVE2,
|
2013-11-30 02:38:16 +04:00
|
|
|
IFLA_HSR_MULTICAST_SPEC, /* Last byte of supervision addr */
|
|
|
|
IFLA_HSR_SUPERVISION_ADDR, /* Supervision frame multicast addr */
|
|
|
|
IFLA_HSR_SEQ_NR,
|
2016-04-20 10:08:29 +03:00
|
|
|
IFLA_HSR_VERSION, /* HSR version */
|
2020-07-22 17:40:16 +03:00
|
|
|
IFLA_HSR_PROTOCOL, /* Indicate different protocol than
|
|
|
|
* HSR. For example PRP.
|
|
|
|
*/
|
2013-10-31 00:10:47 +04:00
|
|
|
__IFLA_HSR_MAX,
|
|
|
|
};
|
|
|
|
|
|
|
|
#define IFLA_HSR_MAX (__IFLA_HSR_MAX - 1)
|
|
|
|
|
2016-04-20 18:43:43 +03:00
|
|
|
/* STATS section */
|
|
|
|
|
|
|
|
struct if_stats_msg {
|
|
|
|
__u8 family;
|
|
|
|
__u8 pad1;
|
|
|
|
__u16 pad2;
|
|
|
|
__u32 ifindex;
|
|
|
|
__u32 filter_mask;
|
|
|
|
};
|
|
|
|
|
|
|
|
/* A stats attribute can be netdev specific or a global stat.
|
|
|
|
* For netdev stats, lets use the prefix IFLA_STATS_LINK_*
|
|
|
|
*/
|
|
|
|
enum {
|
|
|
|
IFLA_STATS_UNSPEC, /* also used as 64bit pad attribute */
|
|
|
|
IFLA_STATS_LINK_64,
|
2016-04-30 11:25:27 +03:00
|
|
|
IFLA_STATS_LINK_XSTATS,
|
2016-06-28 17:57:05 +03:00
|
|
|
IFLA_STATS_LINK_XSTATS_SLAVE,
|
2016-09-16 16:05:37 +03:00
|
|
|
IFLA_STATS_LINK_OFFLOAD_XSTATS,
|
2017-01-16 17:16:36 +03:00
|
|
|
IFLA_STATS_AF_SPEC,
|
2016-04-20 18:43:43 +03:00
|
|
|
__IFLA_STATS_MAX,
|
|
|
|
};
|
|
|
|
|
|
|
|
#define IFLA_STATS_MAX (__IFLA_STATS_MAX - 1)
|
|
|
|
|
|
|
|
#define IFLA_STATS_FILTER_BIT(ATTR) (1 << (ATTR - 1))
|
|
|
|
|
2022-03-02 19:31:17 +03:00
|
|
|
enum {
|
|
|
|
IFLA_STATS_GETSET_UNSPEC,
|
|
|
|
IFLA_STATS_GET_FILTERS, /* Nest of IFLA_STATS_LINK_xxx, each a u32 with
|
|
|
|
* a filter mask for the corresponding group.
|
|
|
|
*/
|
2022-03-02 19:31:23 +03:00
|
|
|
IFLA_STATS_SET_OFFLOAD_XSTATS_L3_STATS, /* 0 or 1 as u8 */
|
2022-03-02 19:31:17 +03:00
|
|
|
__IFLA_STATS_GETSET_MAX,
|
|
|
|
};
|
|
|
|
|
|
|
|
#define IFLA_STATS_GETSET_MAX (__IFLA_STATS_GETSET_MAX - 1)
|
|
|
|
|
2016-04-30 11:25:27 +03:00
|
|
|
/* These are embedded into IFLA_STATS_LINK_XSTATS:
|
|
|
|
* [IFLA_STATS_LINK_XSTATS]
|
|
|
|
* -> [LINK_XSTATS_TYPE_xxx]
|
|
|
|
* -> [rtnl link type specific attributes]
|
|
|
|
*/
|
|
|
|
enum {
|
|
|
|
LINK_XSTATS_TYPE_UNSPEC,
|
2016-04-30 11:25:29 +03:00
|
|
|
LINK_XSTATS_TYPE_BRIDGE,
|
2019-01-18 15:30:23 +03:00
|
|
|
LINK_XSTATS_TYPE_BOND,
|
2016-04-30 11:25:27 +03:00
|
|
|
__LINK_XSTATS_TYPE_MAX
|
|
|
|
};
|
|
|
|
#define LINK_XSTATS_TYPE_MAX (__LINK_XSTATS_TYPE_MAX - 1)
|
|
|
|
|
2016-09-16 16:05:37 +03:00
|
|
|
/* These are stats embedded into IFLA_STATS_LINK_OFFLOAD_XSTATS */
|
|
|
|
enum {
|
|
|
|
IFLA_OFFLOAD_XSTATS_UNSPEC,
|
|
|
|
IFLA_OFFLOAD_XSTATS_CPU_HIT, /* struct rtnl_link_stats64 */
|
net: rtnetlink: Add UAPI for obtaining L3 offload xstats
Add a new IFLA_STATS_LINK_OFFLOAD_XSTATS child attribute,
IFLA_OFFLOAD_XSTATS_L3_STATS, to carry statistics for traffic that takes
place in a HW router.
The offloaded HW stats are designed to allow per-netdevice enablement and
disablement. Additionally, as a netdevice is configured, it may become or
cease being suitable for binding of a HW counter. Both of these aspects
need to be communicated to the userspace. To that end, add another child
attribute, IFLA_OFFLOAD_XSTATS_HW_S_INFO:
- attr nest IFLA_OFFLOAD_XSTATS_HW_S_INFO
- attr nest IFLA_OFFLOAD_XSTATS_L3_STATS
- attr IFLA_OFFLOAD_XSTATS_HW_S_INFO_REQUEST
- {0,1} as u8
- attr IFLA_OFFLOAD_XSTATS_HW_S_INFO_USED
- {0,1} as u8
Thus this one attribute is a nest that can be used to carry information
about various types of HW statistics, and indexing is very simply done by
wrapping the information for a given statistics suite into the attribute
that carries the suite is the RTM_GETSTATS query. At the same time, because
_HW_S_INFO is nested directly below IFLA_STATS_LINK_OFFLOAD_XSTATS, it is
possible through filtering to request only the metadata about individual
statistics suites, without having to hit the HW to get the actual counters.
Signed-off-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2022-03-02 19:31:21 +03:00
|
|
|
IFLA_OFFLOAD_XSTATS_HW_S_INFO, /* HW stats info. A nest */
|
|
|
|
IFLA_OFFLOAD_XSTATS_L3_STATS, /* struct rtnl_hw_stats64 */
|
2016-09-16 16:05:37 +03:00
|
|
|
__IFLA_OFFLOAD_XSTATS_MAX
|
|
|
|
};
|
|
|
|
#define IFLA_OFFLOAD_XSTATS_MAX (__IFLA_OFFLOAD_XSTATS_MAX - 1)
|
|
|
|
|
net: rtnetlink: Add UAPI for obtaining L3 offload xstats
Add a new IFLA_STATS_LINK_OFFLOAD_XSTATS child attribute,
IFLA_OFFLOAD_XSTATS_L3_STATS, to carry statistics for traffic that takes
place in a HW router.
The offloaded HW stats are designed to allow per-netdevice enablement and
disablement. Additionally, as a netdevice is configured, it may become or
cease being suitable for binding of a HW counter. Both of these aspects
need to be communicated to the userspace. To that end, add another child
attribute, IFLA_OFFLOAD_XSTATS_HW_S_INFO:
- attr nest IFLA_OFFLOAD_XSTATS_HW_S_INFO
- attr nest IFLA_OFFLOAD_XSTATS_L3_STATS
- attr IFLA_OFFLOAD_XSTATS_HW_S_INFO_REQUEST
- {0,1} as u8
- attr IFLA_OFFLOAD_XSTATS_HW_S_INFO_USED
- {0,1} as u8
Thus this one attribute is a nest that can be used to carry information
about various types of HW statistics, and indexing is very simply done by
wrapping the information for a given statistics suite into the attribute
that carries the suite is the RTM_GETSTATS query. At the same time, because
_HW_S_INFO is nested directly below IFLA_STATS_LINK_OFFLOAD_XSTATS, it is
possible through filtering to request only the metadata about individual
statistics suites, without having to hit the HW to get the actual counters.
Signed-off-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2022-03-02 19:31:21 +03:00
|
|
|
enum {
|
|
|
|
IFLA_OFFLOAD_XSTATS_HW_S_INFO_UNSPEC,
|
|
|
|
IFLA_OFFLOAD_XSTATS_HW_S_INFO_REQUEST, /* u8 */
|
|
|
|
IFLA_OFFLOAD_XSTATS_HW_S_INFO_USED, /* u8 */
|
|
|
|
__IFLA_OFFLOAD_XSTATS_HW_S_INFO_MAX,
|
|
|
|
};
|
|
|
|
#define IFLA_OFFLOAD_XSTATS_HW_S_INFO_MAX \
|
|
|
|
(__IFLA_OFFLOAD_XSTATS_HW_S_INFO_MAX - 1)
|
|
|
|
|
2016-07-19 22:16:49 +03:00
|
|
|
/* XDP section */
|
|
|
|
|
2016-11-29 01:16:54 +03:00
|
|
|
#define XDP_FLAGS_UPDATE_IF_NOEXIST (1U << 0)
|
2017-05-12 02:04:45 +03:00
|
|
|
#define XDP_FLAGS_SKB_MODE (1U << 1)
|
|
|
|
#define XDP_FLAGS_DRV_MODE (1U << 2)
|
2017-06-22 04:25:04 +03:00
|
|
|
#define XDP_FLAGS_HW_MODE (1U << 3)
|
2020-03-25 20:23:26 +03:00
|
|
|
#define XDP_FLAGS_REPLACE (1U << 4)
|
2017-06-22 04:25:04 +03:00
|
|
|
#define XDP_FLAGS_MODES (XDP_FLAGS_SKB_MODE | \
|
|
|
|
XDP_FLAGS_DRV_MODE | \
|
|
|
|
XDP_FLAGS_HW_MODE)
|
2017-04-18 22:36:58 +03:00
|
|
|
#define XDP_FLAGS_MASK (XDP_FLAGS_UPDATE_IF_NOEXIST | \
|
2020-03-25 20:23:26 +03:00
|
|
|
XDP_FLAGS_MODES | XDP_FLAGS_REPLACE)
|
2016-11-29 01:16:54 +03:00
|
|
|
|
xdp: refine xdp api with regards to generic xdp
While working on the iproute2 generic XDP frontend, I noticed that
as of right now it's possible to have native *and* generic XDP
programs loaded both at the same time for the case when a driver
supports native XDP.
The intended model for generic XDP from b5cdae3291f7 ("net: Generic
XDP") is, however, that only one out of the two can be present at
once which is also indicated as such in the XDP netlink dump part.
The main rationale for generic XDP is to ease accessibility (in
case a driver does not yet have XDP support) and to generically
provide a semantical model as an example for driver developers
wanting to add XDP support. The generic XDP option for an XDP
aware driver can still be useful for comparing and testing both
implementations.
However, it is not intended to have a second XDP processing stage
or layer with exactly the same functionality of the first native
stage. Only reason could be to have a partial fallback for future
XDP features that are not supported yet in the native implementation
and we probably also shouldn't strive for such fallback and instead
encourage native feature support in the first place. Given there's
currently no such fallback issue or use case, lets not go there yet
if we don't need to.
Therefore, change semantics for loading XDP and bail out if the
user tries to load a generic XDP program when a native one is
present and vice versa. Another alternative to bailing out would
be to handle the transition from one flavor to another gracefully,
but that would require to bring the device down, exchange both
types of programs, and bring it up again in order to avoid a tiny
window where a packet could hit both hooks. Given this complicates
the logic for just a debugging feature in the native case, I went
with the simpler variant.
For the dump, remove IFLA_XDP_FLAGS that was added with b5cdae3291f7
and reuse IFLA_XDP_ATTACHED for indicating the mode. Dumping all
or just a subset of flags that were used for loading the XDP prog
is suboptimal in the long run since not all flags are useful for
dumping and if we start to reuse the same flag definitions for
load and dump, then we'll waste bit space. What we really just
want is to dump the mode for now.
Current IFLA_XDP_ATTACHED semantics are: nothing was installed (0),
a program is running at the native driver layer (1). Thus, add a
mode that says that a program is running at generic XDP layer (2).
Applications will handle this fine in that older binaries will
just indicate that something is attached at XDP layer, effectively
this is similar to IFLA_XDP_FLAGS attr that we would have had
modulo the redundancy.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-05-12 02:04:46 +03:00
|
|
|
/* These are stored into IFLA_XDP_ATTACHED on dump. */
|
|
|
|
enum {
|
|
|
|
XDP_ATTACHED_NONE = 0,
|
|
|
|
XDP_ATTACHED_DRV,
|
|
|
|
XDP_ATTACHED_SKB,
|
2017-06-22 04:25:09 +03:00
|
|
|
XDP_ATTACHED_HW,
|
2018-07-12 06:36:41 +03:00
|
|
|
XDP_ATTACHED_MULTI,
|
xdp: refine xdp api with regards to generic xdp
While working on the iproute2 generic XDP frontend, I noticed that
as of right now it's possible to have native *and* generic XDP
programs loaded both at the same time for the case when a driver
supports native XDP.
The intended model for generic XDP from b5cdae3291f7 ("net: Generic
XDP") is, however, that only one out of the two can be present at
once which is also indicated as such in the XDP netlink dump part.
The main rationale for generic XDP is to ease accessibility (in
case a driver does not yet have XDP support) and to generically
provide a semantical model as an example for driver developers
wanting to add XDP support. The generic XDP option for an XDP
aware driver can still be useful for comparing and testing both
implementations.
However, it is not intended to have a second XDP processing stage
or layer with exactly the same functionality of the first native
stage. Only reason could be to have a partial fallback for future
XDP features that are not supported yet in the native implementation
and we probably also shouldn't strive for such fallback and instead
encourage native feature support in the first place. Given there's
currently no such fallback issue or use case, lets not go there yet
if we don't need to.
Therefore, change semantics for loading XDP and bail out if the
user tries to load a generic XDP program when a native one is
present and vice versa. Another alternative to bailing out would
be to handle the transition from one flavor to another gracefully,
but that would require to bring the device down, exchange both
types of programs, and bring it up again in order to avoid a tiny
window where a packet could hit both hooks. Given this complicates
the logic for just a debugging feature in the native case, I went
with the simpler variant.
For the dump, remove IFLA_XDP_FLAGS that was added with b5cdae3291f7
and reuse IFLA_XDP_ATTACHED for indicating the mode. Dumping all
or just a subset of flags that were used for loading the XDP prog
is suboptimal in the long run since not all flags are useful for
dumping and if we start to reuse the same flag definitions for
load and dump, then we'll waste bit space. What we really just
want is to dump the mode for now.
Current IFLA_XDP_ATTACHED semantics are: nothing was installed (0),
a program is running at the native driver layer (1). Thus, add a
mode that says that a program is running at generic XDP layer (2).
Applications will handle this fine in that older binaries will
just indicate that something is attached at XDP layer, effectively
this is similar to IFLA_XDP_FLAGS attr that we would have had
modulo the redundancy.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-05-12 02:04:46 +03:00
|
|
|
};
|
|
|
|
|
2016-07-19 22:16:49 +03:00
|
|
|
enum {
|
|
|
|
IFLA_XDP_UNSPEC,
|
|
|
|
IFLA_XDP_FD,
|
|
|
|
IFLA_XDP_ATTACHED,
|
2016-11-29 01:16:54 +03:00
|
|
|
IFLA_XDP_FLAGS,
|
2017-06-16 03:29:09 +03:00
|
|
|
IFLA_XDP_PROG_ID,
|
2018-07-12 06:36:38 +03:00
|
|
|
IFLA_XDP_DRV_PROG_ID,
|
|
|
|
IFLA_XDP_SKB_PROG_ID,
|
|
|
|
IFLA_XDP_HW_PROG_ID,
|
2020-03-25 20:23:26 +03:00
|
|
|
IFLA_XDP_EXPECTED_FD,
|
2016-07-19 22:16:49 +03:00
|
|
|
__IFLA_XDP_MAX,
|
|
|
|
};
|
|
|
|
|
|
|
|
#define IFLA_XDP_MAX (__IFLA_XDP_MAX - 1)
|
|
|
|
|
2017-05-27 17:14:34 +03:00
|
|
|
enum {
|
|
|
|
IFLA_EVENT_NONE,
|
|
|
|
IFLA_EVENT_REBOOT, /* internal reset / reboot */
|
|
|
|
IFLA_EVENT_FEATURES, /* change in offload features */
|
|
|
|
IFLA_EVENT_BONDING_FAILOVER, /* change in active slave */
|
|
|
|
IFLA_EVENT_NOTIFY_PEERS, /* re-sent grat. arp/ndisc */
|
|
|
|
IFLA_EVENT_IGMP_RESEND, /* re-sent IGMP JOIN */
|
|
|
|
IFLA_EVENT_BONDING_OPTIONS, /* change in bonding options */
|
|
|
|
};
|
|
|
|
|
2018-02-16 13:03:07 +03:00
|
|
|
/* tun section */
|
|
|
|
|
|
|
|
enum {
|
|
|
|
IFLA_TUN_UNSPEC,
|
|
|
|
IFLA_TUN_OWNER,
|
|
|
|
IFLA_TUN_GROUP,
|
|
|
|
IFLA_TUN_TYPE,
|
|
|
|
IFLA_TUN_PI,
|
|
|
|
IFLA_TUN_VNET_HDR,
|
|
|
|
IFLA_TUN_PERSIST,
|
|
|
|
IFLA_TUN_MULTI_QUEUE,
|
|
|
|
IFLA_TUN_NUM_QUEUES,
|
|
|
|
IFLA_TUN_NUM_DISABLED_QUEUES,
|
|
|
|
__IFLA_TUN_MAX,
|
|
|
|
};
|
|
|
|
|
|
|
|
#define IFLA_TUN_MAX (__IFLA_TUN_MAX - 1)
|
|
|
|
|
2018-03-22 04:48:14 +03:00
|
|
|
/* rmnet section */
|
|
|
|
|
|
|
|
#define RMNET_FLAGS_INGRESS_DEAGGREGATION (1U << 0)
|
|
|
|
#define RMNET_FLAGS_INGRESS_MAP_COMMANDS (1U << 1)
|
|
|
|
#define RMNET_FLAGS_INGRESS_MAP_CKSUMV4 (1U << 2)
|
|
|
|
#define RMNET_FLAGS_EGRESS_MAP_CKSUMV4 (1U << 3)
|
2021-06-01 22:28:35 +03:00
|
|
|
#define RMNET_FLAGS_INGRESS_MAP_CKSUMV5 (1U << 4)
|
2021-06-01 22:28:36 +03:00
|
|
|
#define RMNET_FLAGS_EGRESS_MAP_CKSUMV5 (1U << 5)
|
2018-03-22 04:48:14 +03:00
|
|
|
|
|
|
|
enum {
|
|
|
|
IFLA_RMNET_UNSPEC,
|
|
|
|
IFLA_RMNET_MUX_ID,
|
|
|
|
IFLA_RMNET_FLAGS,
|
|
|
|
__IFLA_RMNET_MAX,
|
|
|
|
};
|
|
|
|
|
|
|
|
#define IFLA_RMNET_MAX (__IFLA_RMNET_MAX - 1)
|
|
|
|
|
|
|
|
struct ifla_rmnet_flags {
|
|
|
|
__u32 flags;
|
|
|
|
__u32 mask;
|
|
|
|
};
|
|
|
|
|
2021-07-29 05:20:44 +03:00
|
|
|
/* MCTP section */
|
|
|
|
|
|
|
|
enum {
|
|
|
|
IFLA_MCTP_UNSPEC,
|
|
|
|
IFLA_MCTP_NET,
|
|
|
|
__IFLA_MCTP_MAX,
|
|
|
|
};
|
|
|
|
|
|
|
|
#define IFLA_MCTP_MAX (__IFLA_MCTP_MAX - 1)
|
|
|
|
|
2012-10-13 13:46:48 +04:00
|
|
|
#endif /* _UAPI_LINUX_IF_LINK_H */
|