ip: add 'xdpstats' command to print generic XDP stats #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Owner
alobakin
commented
Oct 7, 2021
•
alobakin
commented
When configuring a devlink PCI SF port, the sfnumber can be specified using 'sfnum' and not 'pcisf' as stated in the man page. Fix this. Signed-off-by: Antoine Tenart <atenart@kernel.org> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Values should be .I, square brackets should be used for optional values, curly brackets for lists. Follow this in the devlink-port man page. Signed-off-by: Antoine Tenart <atenart@kernel.org> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
br. were added between options of the same command. That is not needed and makes the output to be one 3 lines for no particular reason. Signed-off-by: Antoine Tenart <atenart@kernel.org> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
When creating map-in-maps, the outer map can be prepopulated using the inner_idx field of inner maps. That field defines the index of the inner map in the outer map. It is ignored if set to -1. Commit 6d61a2b ("lib: add libbpf support") however started using that field to identify inner maps. While iterating over all maps looking for inner maps, maps with inner_idx set to -1 are erroneously skipped. As a result, trying to create a map-in-map with prepopulation disabled fails because the inner_id of the outer map is not correctly set. This bug can be observed with strace -ebpf (notice the zero inner_map_fd for the outer map creation): bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_ARRAY, key_size=4, value_size=130996, max_entries=1, map_flags=0, inner_map_fd=0, map_name="maglev_inner", map_ifindex=0, btf_fd=0, btf_key_type_id=0, btf_value_type_id=0}, 128) = 32 bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_HASH_OF_MAPS, key_size=2, value_size=4, max_entries=65536, map_flags=BPF_F_NO_PREALLOC, inner_map_fd=0, map_name="maglev_outer", map_ifindex=0, btf_fd=0, btf_key_type_id=0, btf_value_type_id=0}, 128) = -1 EINVAL (Invalid argument) Fixes: 6d61a2b ("lib: add libbpf support") Signed-off-by: Paul Chaignon <paul@isovalent.com> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
See kernel
Commit 844f7eaaed9 ("include/uapi/linux/xfrm.h: Fix XFRM_MSG_MAPPING ABI breakage")
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
alobakin
force-pushed
the
xdp_stats
branch
2 times, most recently
from
f69d9d3
to
73b34f8
Compare
Two new commands to manage default policies: - ip xfrm policy setdefault - ip xfrm policy getdefault And the corresponding part in 'ip xfrm monitor'. Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: David Ahern <dsahern@kernel.org>
Fix up spacing to consistently add a single ' ' after an attribute has been printed. Currently, it is a bit of a mix of before and after which can lead to double spacing to be printed. Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: David Ahern <dsahern@kernel.org>
Currently, ip neigh does not support the NTF_USE flag. Similar to other flags such as extern_learn, add cmdline support. The flag dump support is explicitly missing here, since the kernel does not propagate the flag back to user space. Usage example: # ./ip/ip n replace 192.168.178.30 dev enp5s0 use extern_learn # ./ip/ip n 192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a extern_learn REACHABLE [...] Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: David Ahern <dsahern@kernel.org>
Currently, ip neigh does not support the NTF_EXT_MANAGED flag. Add cmdline support. Usage example: # ./ip/ip n replace 192.168.178.30 dev enp5s0 managed extern_learn # ./ip/ip n 192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a managed extern_learn REACHABLE [...] Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: David Ahern <dsahern@kernel.org>
Daniel Borkmann says:
====================
iproute2 patches to add support for managed neighbor entries as per recent
net-next commits:
2ed08b5ead3c ("Merge branch 'Managed-Neighbor-Entries'")
c47fedba94bc ("Merge branch 'minor-managed-neighbor-follow-ups'")
====================
Signed-off-by: David Ahern <dsahern@kernel.org>
When configuring a devlink PCI port, the pfnumber can be specified using 'pfnum' and not 'pcipf' as stated in the man page. Fix this. Signed-off-by: Antoine Tenart <atenart@kernel.org> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Fix the json output for the QPs that are associated with the SRQ -
The qpn are now displayed in a json array.
Sample output before the fix:
$ rdma res show srq lqpn 126-141 -j -p
[ {
"ifindex":0,
"ifname":"ibp8s0f0",
"srqn":4,
"type":"BASIC",
"lqpn":["126-128,130-140"],
"pdn":9,
"pid":3581,
"comm":"ibv_srq_pingpon"
},{
"ifindex":0,
"ifname":"ibp8s0f0",
"srqn":5,
"type":"BASIC",
"lqpn":["141"],
"pdn":10,
"pid":3584,
"comm":"ibv_srq_pingpon"
} ]
Sample output after the fix:
$ rdma res show srq lqpn 126-141 -j -p
[ {
"ifindex":0,
"ifname":"ibp8s0f0",
"srqn":4,
"type":"BASIC",
"lqpn":["126-128","130-140"],
"pdn":9,
"pid":3581,
"comm":"ibv_srq_pingpon"
},{
"ifindex":0,
"ifname":"ibp8s0f0",
"srqn":5,
"type":"BASIC",
"lqpn":["141"],
"pdn":10,
"pid":3584,
"comm":"ibv_srq_pingpon"
} ]
Fixes: 9b272e1 ("rdma: Add SRQ resource tracking information")
Signed-off-by: Neta Ostrovsky <netao@nvidia.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
This patch is fixing a bug, when param set user command includes configuration mode which is not supported, the tool may not respond with error if the requested value is 0. In such case cmd_dev_param_set_cb() won't find the requested configuration mode and returns ctx->value as initialized (equal 0). Then cmd_dev_param_set() may find that requested value equals current value and returns success. Fixing the bug by adding a flag cmode_found which is set only if cmd_dev_param_set_cb() finds the requested configuration mode. Fixes: 13925ae ("devlink: Add param command support") Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Update kernel headers to commit:
cc0356d6a02e ("Merge tag 'x86_core_for_v5.16_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip")
Signed-off-by: David Ahern <dsahern@kernel.org>
Impor amt.h uapi from last kernel sync point Signed-off-by: David Ahern <dsahern@kernel.org>
Add basic support for Automatic Multicast Tunneling (AMT) network devices. Signed-off-by: Taehee Yoo <ap420073@gmail.com>
The configuration ranges in print_usage() are taken from "Table 8 -
Time segments' minimum configuration ranges" in section 11.3.1.2
"Configuration of the bit time parameters" of ISO 11898-1.
The standard clearly specifies that "implementations may allow time
segments that exceed the minimum required configuration ranges
specified in Table 8".
Because no maximum ranges are given in the standard, all given ranges
{ a..b } are simply replaced with { NUMBER }.
The actual ranges are specific to each device and can be confirmed
doing:
$ ip --details link show can0
1: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10
link/can promiscuity 0 minmtu 0 maxmtu 0
can state STOPPED restart-ms 0
ES582.1/ES584.1: tseg1 2..256 tseg2 2..128 sjw 1..128 brp 1..512 brp-inc 1
ES582.1/ES584.1: dtseg1 2..32 dtseg2 1..16 dsjw 1..8 dbrp 1..32 dbrp-inc 1
clock 80000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
Finally, the unit (bps, tq, ns or ms) are given. The rationale to add
the units is that the TDC parameters (that will be introduced in the
upcoming patches) are measured in a different unit than the other
bittiming parameters: clock period (a.k.a. minimum time quantum)
instead of time quantum. Adding the units disambiguates things.
For reference, before the change:
$ ip link set can0 type can help
Usage: ip link set DEVICE type can
[ bitrate BITRATE [ sample-point SAMPLE-POINT] ] |
[ tq TQ prop-seg PROP_SEG phase-seg1 PHASE-SEG1
phase-seg2 PHASE-SEG2 [ sjw SJW ] ]
[ dbitrate BITRATE [ dsample-point SAMPLE-POINT] ] |
[ dtq TQ dprop-seg PROP_SEG dphase-seg1 PHASE-SEG1
dphase-seg2 PHASE-SEG2 [ dsjw SJW ] ]
[ loopback { on | off } ]
[ listen-only { on | off } ]
[ triple-sampling { on | off } ]
[ one-shot { on | off } ]
[ berr-reporting { on | off } ]
[ fd { on | off } ]
[ fd-non-iso { on | off } ]
[ presume-ack { on | off } ]
[ restart-ms TIME-MS ]
[ restart ]
[ termination { 0..65535 } ]
Where: BITRATE := { 1..1000000 }
SAMPLE-POINT := { 0.000..0.999 }
TQ := { NUMBER }
PROP-SEG := { 1..8 }
PHASE-SEG1 := { 1..8 }
PHASE-SEG2 := { 1..8 }
SJW := { 1..4 }
RESTART-MS := { 0 | NUMBER }
...and after it:
$ ip link set can0 type can help
Usage: ip link set DEVICE type can
[ bitrate BITRATE [ sample-point SAMPLE-POINT] ] |
[ tq TQ prop-seg PROP_SEG phase-seg1 PHASE-SEG1
phase-seg2 PHASE-SEG2 [ sjw SJW ] ]
[ dbitrate BITRATE [ dsample-point SAMPLE-POINT] ] |
[ dtq TQ dprop-seg PROP_SEG dphase-seg1 PHASE-SEG1
dphase-seg2 PHASE-SEG2 [ dsjw SJW ] ]
[ loopback { on | off } ]
[ listen-only { on | off } ]
[ triple-sampling { on | off } ]
[ one-shot { on | off } ]
[ berr-reporting { on | off } ]
[ fd { on | off } ]
[ fd-non-iso { on | off } ]
[ presume-ack { on | off } ]
[ cc-len8-dlc { on | off } ]
[ restart-ms TIME-MS ]
[ restart ]
[ termination { 0..65535 } ]
Where: BITRATE := { NUMBER in bps }
SAMPLE-POINT := { 0.000..0.999 }
TQ := { NUMBER in ns }
PROP-SEG := { NUMBER in tq }
PHASE-SEG1 := { NUMBER in tq }
PHASE-SEG2 := { NUMBER in tq }
SJW := { NUMBER in tq }
RESTART-MS := { 0 | NUMBER in ms }
Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Signed-off-by: David Ahern <dsahern@kernel.org>
This patch only does cleanup and do not introduce any functional
changes.
We do some code refactoring of print_ctrlmode() in prevision of the
upcoming patch:
- remove the first argument of print_ctrlmode(). It is a pointer to
FILE and is never used.
- add a new function argument: enum output_type t in order to
specify the output type (i.e. PRINT_{FP,JSON,ANY}).
- add a new function argument: const char *key in order to specify
the name of the json array (e.g. "ctrlmode").
- replace the _PF() macro with the print_flag() function to increase
readability.
- directly return if none of the flags are set (previously, this
check was done before calling the function).
Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Signed-off-by: David Ahern <dsahern@kernel.org>
Current implementation heavily relies on some "if (is_json_context())" switches to decide the context and then does some print_*(PRINT_JSON, ...) when in json context and some fprintf(...) else. Furthermore, current implementation uses either print_int() or the conversion specifier %d to print unsigned integers. This patch factorizes each pairs of print_*(PRINT_JSON, ...) and fprintf() into a single print_*(PRINT_ANY, ...) call. While doing this replacement, it uses proper unsigned function print_uint() as well as the conversion specifier %u when the parameter is an unsigned integer. Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: David Ahern <dsahern@kernel.org>
Report the value of the bit-rate prescaler (brp) for both the nominal
and the data bittiming.
Currently, only the constant brp values (brp_{min,max,inc}) are being
reported. Also, brp is the only member of struct can_bittiming not
being reported.
Noticeably, brp could be calculated by hand from the other bittiming
parameters with below formula:
brp = clock * tq / 1000000000
with clock in hertz and tq in nano second (thus the need of a 1
billion factor to convert it back to second).
But because above formula is not so trivial to remember and is
subjected to rounding errors, it makes sense to directly output
{d,}bpr.
Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Signed-off-by: David Ahern <dsahern@kernel.org>
…mpensation (TDC)
At high bit rates, the propagation delay from the TX pin to the RX pin
of the transceiver causes measurement errors: the sample point on the
RX pin might occur on the previous bit.
This issue is addressed in ISO 11898-1 section 11.3.3 "Transmitter
delay compensation" (TDC).
This patch brings command line support to nine TDC parameters which
were recently added to the kernel's CAN netlink interface in order to
implement TDC:
- IFLA_CAN_TDC_TDCV_MIN: Transmitter Delay Compensation Value
minimum value
- IFLA_CAN_TDC_TDCV_MAX: Transmitter Delay Compensation Value
maximum value
- IFLA_CAN_TDC_TDCO_MIN: Transmitter Delay Compensation Offset
minimum value
- IFLA_CAN_TDC_TDCO_MAX: Transmitter Delay Compensation Offset
maximum value
- IFLA_CAN_TDC_TDCF_MIN: Transmitter Delay Compensation Filter
window minimum value
- IFLA_CAN_TDC_TDCF_MAX: Transmitter Delay Compensation Filter
window maximum value
- IFLA_CAN_TDC_TDCV: Transmitter Delay Compensation Value
- IFLA_CAN_TDC_TDCO: Transmitter Delay Compensation Offset
- IFLA_CAN_TDC_TDCF: Transmitter Delay Compensation Filter window
All those new parameters are nested together into the attribute
IFLA_CAN_TDC.
The TDC parameters extend the FD parameters. As such, the TDC
parameters must be specified together the "fd on" flag.
When "fd on" flag is provided, a tdc-mode parameter allows to specify
how to operate. Valid options for tdc-mode are:
* auto: the transmitter dynamically measures TDCV for each of the
transmitted frames. As such, TDCV can not be manually provided. In
this mode, the user must specify TDCO and may also specify TDCF if
supported.
* manual: use a static TDCV provided by the user. In this mode, the
user must specify both TDCV and TDCO and may also specify TDCF if
supported.
* off: TDC is explicitly disabled.
* tdc-mode parameter omitted (default mode): the kernel decides
whether TDC should be enabled or not and if so, it calculates the
TDC values. TDC parameters are an expert option and the average
user is not expected to provide those, thus the presence of this
"default mode".
If the fd flag is omitted, all the FD values (including TDC values)
remain unchanged.
If "fd off" flag is specified, all FD values (including TDC values)
are zeroed.
TDCV is always reported in manual mode. In auto mode, TDCV is reported
only if the value is available. Especially, the TDCV might not be
available if the controller has no feature to report it or if the
value in not yet available (i.e. no data sent yet and measurement did
not occur).
TDCF is reported only if tdcf_max is not zero (i.e. if supported by
the controller).
For reference, here are a few samples of how the output looks like:
| $ ip link set can0 type can bitrate 1000000 dbitrate 8000000 fd on tdco 7 tdcf 8 tdc-mode auto
| $ ip --details link show can0
| 1: can0: <NOARP,ECHO> mtu 72 qdisc noop state DOWN mode DEFAULT group default qlen 10
| link/can promiscuity 0 minmtu 0 maxmtu 0
| can <FD,TDC-AUTO> state STOPPED (berr-counter tx 0 rx 0) restart-ms 0
| bitrate 1000000 sample-point 0.750
| tq 12 prop-seg 29 phase-seg1 30 phase-seg2 20 sjw 1 brp 1
| ES582.1/ES584.1: tseg1 2..256 tseg2 2..128 sjw 1..128 brp 1..512 brp_inc 1
| dbitrate 8000000 dsample-point 0.700
| dtq 12 dprop-seg 3 dphase-seg1 3 dphase-seg2 3 dsjw 1 dbrp 1
| tdco 7 tdcf 8
| ES582.1/ES584.1: dtseg1 2..32 dtseg2 1..16 dsjw 1..8 dbrp 1..32 dbrp_inc 1
| tdco 0..127 tdcf 0..127
| clock 80000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
| $ ip --details --json --pretty link show can0
| [ {
| "ifindex": 1,
| "ifname": "can0",
| "flags": [ "NOARP","ECHO" ],
| "mtu": 72,
| "qdisc": "noop",
| "operstate": "DOWN",
| "linkmode": "DEFAULT",
| "group": "default",
| "txqlen": 10,
| "link_type": "can",
| "promiscuity": 0,
| "min_mtu": 0,
| "max_mtu": 0,
| "linkinfo": {
| "info_kind": "can",
| "info_data": {
| "ctrlmode": [ "FD","TDC-AUTO" ],
| "state": "STOPPED",
| "berr_counter": {
| "tx": 0,
| "rx": 0
| },
| "restart_ms": 0,
| "bittiming": {
| "bitrate": 1000000,
| "sample_point": "0.750",
| "tq": 12,
| "prop_seg": 29,
| "phase_seg1": 30,
| "phase_seg2": 20,
| "sjw": 1,
| "brp": 1
| },
| "bittiming_const": {
| "name": "ES582.1/ES584.1",
| "tseg1": {
| "min": 2,
| "max": 256
| },
| "tseg2": {
| "min": 2,
| "max": 128
| },
| "sjw": {
| "min": 1,
| "max": 128
| },
| "brp": {
| "min": 1,
| "max": 512
| },
| "brp_inc": 1
| },
| "data_bittiming": {
| "bitrate": 8000000,
| "sample_point": "0.700",
| "tq": 12,
| "prop_seg": 3,
| "phase_seg1": 3,
| "phase_seg2": 3,
| "sjw": 1,
| "brp": 1,
| "tdc": {
| "tdco": 7,
| "tdcf": 8
| }
| },
| "data_bittiming_const": {
| "name": "ES582.1/ES584.1",
| "tseg1": {
| "min": 2,
| "max": 32
| },
| "tseg2": {
| "min": 1,
| "max": 16
| },
| "sjw": {
| "min": 1,
| "max": 8
| },
| "brp": {
| "min": 1,
| "max": 32
| },
| "brp_inc": 1,
| "tdc": {
| "tdco": {
| "min": 0,
| "max": 127
| },
| "tdcf": {
| "min": 0,
| "max": 127
| }
| }
| },
| "clock": 80000000
| }
| },
| "num_tx_queues": 1,
| "num_rx_queues": 1,
| "gso_max_size": 65536,
| "gso_max_segs": 65535
| } ]
Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Signed-off-by: David Ahern <dsahern@kernel.org>
Vincent Mailhol says: ==================== The main purpose is to add commandline support for Transmitter Delay Compensation (TDC) in iproute. Other issues found during the development of this feature also get addressed. This patch series contains four patches which respectively: 1. Correct the bittiming ranges in the print_usage function and add the units to give more clarity: some parameters are in milliseconds, some in nano seconds, some in time quantum and the newly TDC parameters introduced in this series would be in clock period. 2. Do some code refactoring on function print_ctrlmode(). 3. factorize the many print_*(PRINT_JSON, ...) and fprintf occurrences in a single print_*(PRINT_ANY, ...) call and fix the signedness while doing that. 4. report the value of the bitrate prescalers (brp and dbrp). 5. adds command line support for the TDC in iproute and goes together with below series in the kernel: https://lore.kernel.org/linux-can/20210814091750.73931-1-mailhol.vincent@wanadoo.fr/T/#t ** Changelog ** >From RFC v5 to v6: * Dropped the RFC tag because the related patch series on the kernel side were pulled into net-next. * Remove the changes in include/uapi/linux/can/netlink.h because these should be pulled separately. * Add another patch (the second of this series) to do some cleanup on function print_ctrlmode(). * Minor fixes in the patch comments (grammar, rephrasing). >From RFC v4 to RFC v5: * Add the unit (bps, tq, ns or ms) in print_usage() * Rewrote void can_print_timing_min_max() to better factorize the code. * Rewrote the commit message of the two last patches (those related to TDC) to either add clarification of fix inacurracies. >From v3 to RFC v4: * Reflect the changes made on the kernel side. >From RFC v2 to v3: * Dropped the RFC tag. Now that the kernel patch reach the testing branch, I am finaly ready. * Regression fix: configuring a link with only nominal bittiming returned -EOPNOTSUPP * Added two more patches to the series: - iplink_can: fix configuration ranges in print_usage() - iplink_can: print brp and dbrp bittiming variables * Other small fixes on formatting. >From RFC v1 to RFC v2: * Add an additional patch to the series to fix the issues reported by Stephen Hemminger Ref: https://lore.kernel.org/linux-can/20210506112007.1666738-1-mailhol.vincent@wanadoo.fr/T/#t ==================== Signed-off-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David Ahern <dsahern@kernel.org>
vdpa header file is already present in the tree at vdpa/include/uapi/linux/vdpa.h and used by vdpa/vdpa.c. As we discussed in thread [1] vdpa header comes from a different tree, similar to rdma subsystem. Hence remove the duplicate vdpa UAPI header file. [1] https://www.spinics.net/lists/netdev/msg748458.html Fixes: b5a6ed9 ("uapi: add missing virtio related headers") Signed-off-by: Parav Pandit <parav@nvidia.com> Signed-off-by: David Ahern <dsahern@gmail.com>
42df6e1d221d ("netfilter: Introduce egress hook")
7bbbbfaa7a1b ("ether: add EtherType for proprietary Realtek protocols")
dfcb63ce1de6 ("fq_codel: generalise ce_threshold marking for subset of traffic")
c9e8cfb31d18 ("rtnetlink: introduce generic XDP statistics")
Signed-off-by: Alexander Lobakin <alexandr.lobakin@intel.com>
Add 'xdpstats' command to print XDP statistics provided by new generic XDP stats infra. It supports both plain text and JSON output and filtering by interface name and stats type (XDP/XSK). Since one NIC can have hundreds of channels, statistics dump is able to resume on particular channel number, so it works even one Netlink message carries just a part of XSTATS_TYPE_* nest. Signed-off-by: Alexander Lobakin <alexandr.lobakin@intel.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.