When the user asks to show device resources, devlink first queries the
device's dpipe tables so that it will be able to show the association
between resources and dpipe tables.
In this flow, 'ctx->resources' is always NULL as resources have yet to
be retrieved. As a result, the dpipe tables are not associated with a
resource identifier and the resource show command does not show any
dpipe tables:
$ devlink resource show pci/0000:03:00.0
pci/0000:03:00.0:
name kvd size 258048 unit entry dpipe_tables none
resources:
name linear size 98304 occ 1 unit entry size_min 0 size_max 159744 size_gran 128 dpipe_tables none
resources:
name singles size 16384 occ 1 unit entry size_min 0 size_max 159744 size_gran 1 dpipe_tables none
name chunks size 49152 occ 0 unit entry size_min 0 size_max 159744 size_gran 32 dpipe_tables none
name large_chunks size 32768 occ 0 unit entry size_min 0 size_max 159744 size_gran 512 dpipe_tables none
name hash_double size 65408 unit entry size_min 32768 size_max 192512 size_gran 128 dpipe_tables none
name hash_single size 94336 unit entry size_min 65536 size_max 225280 size_gran 128 dpipe_tables none
name span_agents size 3 occ 0 unit entry dpipe_tables none
name counters size 32766 occ 4 unit entry dpipe_tables none
resources:
name rif size 8192 occ 0 unit entry dpipe_tables none
name flow size 24574 occ 4 unit entry dpipe_tables none
name global_policers size 1000 unit entry dpipe_tables none
resources:
name single_rate_policers size 968 occ 0 unit entry dpipe_tables none
name rif_mac_profiles size 1 occ 0 unit entry dpipe_tables none
name rifs size 1000 occ 1 unit entry dpipe_tables none
name port_range_registers size 16 occ 0 unit entry dpipe_tables none
name physical_ports size 64 occ 32 unit entry dpipe_tables none
Fix by moving the check against 'ctx->resources' to the place where it
is actually used. Output after the fix:
$ devlink resource show pci/0000:03:00.0
pci/0000:03:00.0:
name kvd size 258048 unit entry dpipe_tables none
resources:
name linear size 98304 occ 1 unit entry size_min 0 size_max 159744 size_gran 128
dpipe_tables:
table_name mlxsw_adj
resources:
name singles size 16384 occ 1 unit entry size_min 0 size_max 159744 size_gran 1 dpipe_tables none
name chunks size 49152 occ 0 unit entry size_min 0 size_max 159744 size_gran 32 dpipe_tables none
name large_chunks size 32768 occ 0 unit entry size_min 0 size_max 159744 size_gran 512 dpipe_tables none
name hash_double size 65408 unit entry size_min 32768 size_max 192512 size_gran 128
dpipe_tables:
table_name mlxsw_host6
name hash_single size 94336 unit entry size_min 65536 size_max 225280 size_gran 128
dpipe_tables:
table_name mlxsw_host4
name span_agents size 3 occ 0 unit entry dpipe_tables none
name counters size 32766 occ 4 unit entry dpipe_tables none
resources:
name rif size 8192 occ 0 unit entry dpipe_tables none
name flow size 24574 occ 4 unit entry dpipe_tables none
name global_policers size 1000 unit entry dpipe_tables none
resources:
name single_rate_policers size 968 occ 0 unit entry dpipe_tables none
name rif_mac_profiles size 1 occ 0 unit entry dpipe_tables none
name rifs size 1000 occ 1 unit entry dpipe_tables none
name port_range_registers size 16 occ 0 unit entry dpipe_tables none
name physical_ports size 64 occ 32 unit entry dpipe_tables none
Fixes: 0e7e1819453c ("devlink: relax dpipe table show dependency on resources")
Reviewed-by: Petr Machata <petrm@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
The expected size for IFLA_INFO_KIND in kernel is strlen(kind) + 1.
See `size` in rtnl_link_get_size() in net/core/rtnetlink.c.
Fixes: 1d93483985f0 ("iplink: use netlink for link configuration")
Reported-by: Gris Ge <fge@redhat.com>
Signed-off-by: Jan Vaclav <jvaclav@redhat.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
This is the iproute2 counterpart of Linux kernel's commit 46552323fa67
("can: netlink: add PWM netlink interface").
When the TMS is switched on, the node uses PWM (Pulse Width Modulation)
during the data phase instead of the classic NRZ (Non Return to Zero)
encoding.
PWM is configured by three parameters:
- PWMS: Pulse Width Modulation Short phase
- PWML: Pulse Width Modulation Long phase
- PWMO: Pulse Width Modulation Offset time
For each of these parameters, the CAN netlink interface defines three IFLA
symbols:
- IFLA_CAN_PWM_PWM*_MIN: the minimum allowed value.
- IFLA_CAN_PWM_PWM*_MAX: the maximum allowed value.
- IFLA_CAN_PWM_PWM*: the runtime value.
This results in a total of nine IFLA symbols which are all nested in a
parent IFLA_CAN_XL_PWM symbol.
Add the "pwms", "pwml" and "pwmo" options to iplink_can which controls the
IFLA_CAN_PWM_PWM* runtime values.
Add the logic to query and print all those IFLA values. Update
print_usage() accordingly.
Example using the dummy_can driver:
# modprobe dummy_can
# ip link set can0 type can bitrate 1000000 xl on xbitrate 20000000 tms on
$ ip --details link show can0
5: can0: <NOARP> mtu 2060 qdisc noop state DOWN mode DEFAULT group default qlen 10
link/can promiscuity 0 allmulti 0 minmtu 76 maxmtu 2060
can <XL,TMS> state STOPPED restart-ms 0
bitrate 1000000 sample-point 0.750
tq 6 prop-seg 59 phase-seg1 60 phase-seg2 40 sjw 20 brp 1
dummy_can CC: tseg1 2..256 tseg2 2..128 sjw 1..128 brp 1..512 brp_inc 1
dummy_can FD: dtseg1 2..256 dtseg2 2..128 dsjw 1..128 dbrp 1..512 dbrp_inc 1
tdco 0..127 tdcf 0..127
xbitrate 20000000 xsample-point 0.625
xtq 6 xprop-seg 2 xphase-seg1 2 xphase-seg2 3 xsjw 1 xbrp 1
pwms 2 pwml 6 pwmo 0
dummy_can XL: xtseg1 2..256 xtseg2 2..128 xsjw 1..128 xbrp 1..512 xbrp_inc 1
xtdco 0..127 xtdcf 0..127
pwms 1..8 pwml 2..24 pwmo 0..16
clock 160000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536 gso_ipv4_max_size 65536 gro_ipv4_max_size 65536
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
This is the iproute2 counterpart of Linux kernel's commit 233134af2086
("can: netlink: add CAN_CTRLMODE_XL_TMS flag").
The Transceiver Mode Switching (TMS) indicates whether the CAN XL
controller shall use the PWM or NRZ encoding during the data phase.
The term "transceiver mode switching" is used in both ISO 11898-1 and CiA
612-2 (although only the latter one uses the abbreviation TMS). We adopt
the same naming convention here for consistency.
Add the "tms" option to iplink_can which controls the CAN_CTRLMODE_XL_TMS
flag of the CAN netlink interface.
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
This is the iproute2 counterpart of Linux kernel's commit e63281614747
("can: netlink: add initial CAN XL support").
CAN XL uses bittiming parameters different from Classical CAN and CAN FD.
Thus, all the data bittiming parameters, including TDC, need to be
duplicated for CAN XL.
Add the "xl" option to iplink_can which controls the CAN_CTRLMODE_XL flag
of the netlink interface. Then add the "xbitrate", "xsample-point", "xtq",
"xprop-seg", "xphase-seg1", "xphase-seg2", "xsjw", "xtdcv", "xtdco",
"xtdcf" and "xtdc-mode" which are all sub options of "xl". Add the logic to
query and print all those values. Update print_usage() accordingly.
All these options behave similarly to their CAN FD equivalent.
The new options which are specific to CAN XL (i.e. not inherited from CAN
FD) will be added in a subsequent change.
Example using the dummy_can driver:
# modprobe dummy_can
# ip link set can0 type can bitrate 500000 fd on dbitrate 2000000 xl on xbitrate 8000000
$ ip --details link show can0
5: can0: <NOARP> mtu 2060 qdisc noop state DOWN mode DEFAULT group default qlen 10
link/can promiscuity 0 allmulti 0 minmtu 76 maxmtu 2060
can <FD,TDC-AUTO,XL,XL-TDC-AUTO> state STOPPED restart-ms 0
bitrate 500000 sample-point 0.875
tq 12 prop-seg 69 phase-seg1 70 phase-seg2 20 sjw 10 brp 2
dummy_can CC: tseg1 2..256 tseg2 2..128 sjw 1..128 brp 1..512 brp_inc 1
dbitrate 2000000 dsample-point 0.750
dtq 6 dprop-seg 29 dphase-seg1 30 dphase-seg2 20 dsjw 10 dbrp 1
tdco 60 tdcf 0
dummy_can FD: dtseg1 2..256 dtseg2 2..128 dsjw 1..128 dbrp 1..512 dbrp_inc 1
tdco 0..127 tdcf 0..127
xbitrate 8000000 xsample-point 0.750
xtq 6 xprop-seg 7 xphase-seg1 7 xphase-seg2 5 xsjw 2 xbrp 1
xtdco 15 xtdcf 0
dummy_can XL: xtseg1 2..256 xtseg2 2..128 xsjw 1..128 xbrp 1..512 xbrp_inc 1
xtdco 0..127 xtdcf 0..127
clock 160000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536 gso_ipv4_max_size 65536 gro_ipv4_max_size 65536
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
This is the iproute2 counterpart of Linux kernel's commit 60f511f443e5
("can: netlink: add CAN_CTRLMODE_RESTRICTED").
ISO 11898-1:2024 adds a new restricted operation mode. This mode is added
as a mandatory feature for nodes which support CAN XL and is retrofitted as
optional for legacy nodes (i.e. the ones which only support Classical CAN
and CAN FD).
The restricted operation mode is nearly the same as the listen only mode:
the node can not send data frames or remote frames and can not send
dominant bits if an error occurs. The only exception is that the node shall
still send the acknowledgment bit.
Add the "restricted" option to iplink_can which controls the
CAN_CTRLMODE_RESTRICTED flag of the netlink interface.
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
While the meaning of "bps" or "ns" may be relatively easy to understand,
some of the CAN specific units such as "mtq" (minimum time quanta) may be
harder to understand.
Add a new paragraph to the help menu which describes all the different
units used for the CAN bittiming parameters.
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
In the vast majority of the available CAN datasheets, the minimum time
quanta is abbreviated as "mtq". Note that the ISO standard uses "tqmin"
(with the "min" part as a subscript).
One fact is that no one seems to be using "tc". I was actually the one who
initially proposed to use "tc", but I can not recall anymore the reasoning
behind that.
Change the minimum time quanta unit from "tc" to "mtq" to follow what the
majority of the industry does.
Fixes: 0c263d7c36ff ("iplink_can: add new CAN FD bittiming parameters: Transmitter Delay Compensation (TDC)")
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
The description of the BITRATE variable is not correctly aligned with the
other ones. Put it on a new line with the same indentation as the other
variables.
This done, reindent everything to only one tabulation (was one tabulation
and two spaces before).
Before this patch...:
$ ip link help can
Usage: ip link set DEVICE type can
(...)
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 }
TDCV := { NUMBER in tc }
TDCO := { NUMBER in tc }
TDCF := { NUMBER in tc }
RESTART-MS := { 0 | NUMBER in ms }
...and after:
$ ip link help can
Usage: ip link set DEVICE type can
(...)
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 }
TDCV := { NUMBER in tc }
TDCO := { NUMBER in tc }
TDCF := { NUMBER in tc }
RESTART-MS := { 0 | NUMBER in ms }
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
- utils_math.c:136:20: error: 'UINT_MAX' undeclared (first use in this function)
- tc_core.c:51:22: error: 'UINT_MAX' undeclared (first use in this function)
Signed-off-by: Akhilesh Nema <nemaakhilesh@gmail.com>
In the v6.18 kernel, the 'server side' attribute has been deprecated [1]
in favour of the 'server side' flag [2].
Support both: first checking the new flag, then the old attribute to
continue supporting older kernels.
Link: https://git.kernel.org/torvalds/c/c8bc168f5f3d [1]
Link: https://git.kernel.org/torvalds/c/3d7ae91107b8 [2]
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: David Ahern <dsahern@kernel.org>
Until recently, the 'flags' attribute was not used. This has recently
been changed with the introduction of the 'deny_join_id0' flag [1].
This flag is set when a connection is created and the other peer set the
'C' flag in the MP_CAPABLE packets [2]. This flag can be set to tell the
other side that the peer will not accept extra subflows requests sent to
its initial IP address and port: typically set by a server behind a
legacy Layer 4 load balancer.
Now, when this flag is set, "deny_join_id0" will be printed instead of
"flags=1". Unknown remaining flags will be printed in hexadecimal at the
end, e.g. "flags=0x2".
Link: https://git.kernel.org/torvalds/c/2293c57484ae [1]
Link: https://datatracker.ietf.org/doc/html/rfc8684#section-3.1-20.6 [2]
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: David Ahern <dsahern@kernel.org>
This info has been added a while ago in the kernel [1], but it was not
displayed in 'ip monitor'.
Now, 'server_side' is displayed if the attribute is defined and set to
true. It looks better to do that instead of showing server_side=0. Note
that since v6.18 [2], this attribute is only defined if it is set to
true.
Link: https://git.kernel.org/torvalds/c/41b3c69bf941 [1]
Link: https://git.kernel.org/torvalds/c/c9809f03c158 [2]
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: David Ahern <dsahern@kernel.org>
This new endpoint type has been recently added to the kernel in v6.18
[1]. It will be used to create new subflows from the associated address
to additional addresses announced by the other peer. This will be done
if allowed by the MPTCP limits, and if the associated address is not
already being used by another subflow from the same MPTCP connection.
Note that the fullmesh flag takes precedence over the laminar one.
Without any of these two flags, the path-manager will create new
subflows to additional addresses announced by the other peer by
selecting the source address from the routing tables, which is harder to
configure if the announced address is not known in advance.
The support of the new flag is easy: simply by adding it in the
mptcp_addr_flag_names array.
The usage menu and the manual now references the new endpoint type. The
new corresponding counter has also been added in ss.
Link: https://git.kernel.org/torvalds/c/539f6b9de39e [1]
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: David Ahern <dsahern@kernel.org>
Add Matthieu as main maintainer, but also the MPTCP Linux mailing list
to reach more people interested by MPTCP when submitting patches on this
subject.
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: David Ahern <dsahern@kernel.org>
The set of processes attached to tuntap are displayed
as JSON array, but was missing the inner brackets to
allow for multiple processes.
Fixes: 689bef5dc97a ("tuntap: support JSON output")
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
The function nl_print_policy was only used in the genl code
so it should be moved to that file.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: David Ahern <dsahern@kernel.org>
Cleanup the old code and support for JSON output.
The non-json output is the same as before the patch.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: David Ahern <dsahern@kernel.org>
Petr Oros says:
====================
This patch series adds a new userspace tool for managing and monitoring
DPLL (Digital Phase-Locked Loop) devices via the Linux kernel DPLL
subsystem.
The series includes preparatory patches to move shared code to lib/ and
the main dpll tool implementation with full support for device/pin
management, monitoring, and JSON output.
====================
Signed-off-by: David Ahern <dsahern@kernel.org>
Add a new userspace tool for managing and monitoring DPLL devices via the
Linux kernel DPLL subsystem. The tool uses libmnl for netlink communication
and provides a complete interface for device and pin configuration.
The tool supports:
- Device management: enumerate devices, query capabilities (lock status,
temperature, supported modes, clock quality levels), configure phase-offset
monitoring and averaging
- Pin management: enumerate pins with hierarchical relationships, configure
frequencies (including esync), phase adjustments, priorities, states, and
directions
- Complex topologies: handle parent-device and parent-pin relationships,
reference synchronization tracking, multi-attribute queries (frequency
ranges, capabilities)
- ID resolution: query device/pin IDs by various attributes (module-name,
clock-id, board-label, type)
- Monitoring: real-time display of device and pin state changes via netlink
multicast notifications
- Output formats: both human-readable and JSON output (with pretty-print
support)
The tool belongs in iproute2 as DPLL devices are tightly integrated with
network interfaces - modern NICs provide hardware clock synchronization
support. The DPLL subsystem uses the same netlink infrastructure as other
networking subsystems, and the tool follows established iproute2 patterns
for command structure, output formatting, and error handling.
Example usage:
# dpll device show
# dpll device id-get module-name ice
# dpll device set id 0 phase-offset-monitor enable
# dpll pin show
# dpll pin set id 0 frequency 10000000
# dpll pin set id 13 parent-device 0 state connected prio 10
# dpll pin set id 0 reference-sync 1 state connected
# dpll monitor
# dpll -j -p device show
Testing notes:
Tested on real hardware with ice and zl3073x drivers. All commands work
(device show/set/id-get, pin show/set/id-get, monitor). JSON output was
carefully compared with cli.py - the tools are interchangeable.
v2:
- Added testing notes
- Added MAINTAINERS entry
- Removed unused -n parameter from man page
v3:
- Use shared mnlg and str_to_bool helpers from lib
- Use str_num_map for bidirectional string/enum mapping
- Remove unnecessary else after return
- Remove misleading "legacy" comments
- Simplify DPLL_PR_MULTI_ENUM_STR macro
- Convert json_output to global json variable
- Use appropriate mnl helpers with proper type casting to respect signed integer data types
- Use DPLL_PR_INT_FMT for phase-adjust-gran to respect signed integer type
- Remove dpll_link from Makefile (mistake in v2)
v4:
- Replace DPLL_PR_MULTI_ENUM_STR macro with dpll_pr_multi_enum_str() function
- Replace pr_out("\n") with print_nl() for one-line mode support
- Remove all is_json_context() code splitting, use PRINT_FP/PRINT_JSON/PRINT_ANY appropriately
- Add dpll_pr_freq_range() helper function to reduce code duplication
v5
- Fix checkpatch warnings
- Use structure initialization instead of memset
- Use sigemptyset() for proper signal mask initialization
- Remove redundant if (json) checks around JSON functions
- Use signalfd for signal handling in monitor
- Set netlink socket to non-blocking in monitor
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Co-developed-by: Ivan Vecera <ivecera@redhat.com>
Signed-off-by: Petr Oros <poros@redhat.com>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
Add str_to_bool() helper function to lib/utils.c that uses
parse_one_of() to parse boolean values. Update devlink to
use this common implementation.
Signed-off-by: Petr Oros <poros@redhat.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
Move mnlg.c to lib/ and mnlg.h to include/ to allow code reuse
across multiple tools.
Signed-off-by: Petr Oros <poros@redhat.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
Add support for the new inactive switchdev mode [1].
A user can start the eswitch in switchdev or switchdev_inactive mode.
Active: Traffic is enabled on this eswitch FDB.
Inactive: Traffic is ignored/dropped on this eswitch FDB.
An example use case:
$ devlink dev eswitch set pci/0000:08:00.1 mode switchdev_inactive
Setup FDB pipeline and netdev representors
...
Once ready to start receiving traffic
$ devlink dev eswitch set pci/0000:08:00.1 mode switchdev
[1] https://lore.kernel.org/all/20251107000831.157375-1-saeed@kernel.org/
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
Clang complains that the variable 'n' used for nlmsghdr is passed
uninitiailized. Remove it because it is never used.
Fixes: 6f7779ad4ef6 ("netshaper: Add netshaper command")
Cc: ernis@linux.microsoft.com
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Kernel commit c0ef144695910 ("devlink: Add support for u64 parameters")
added support for 64bit devlink parameters, add the support for them
also into devlink utility userspace counterpart.
Tested on Microchip EDS2 development board...
Prior patch:
root@eds2:~# devlink dev param set i2c/1-0070 name clock_id value 1234 cmode driverinit
Value type not supported
root@eds2:~#
After patch:
root@eds2:~# devlink dev param set i2c/1-0070 name clock_id value 1234 cmode driverinit
root@eds2:~#
Cc: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
The kernel supports passing the XFRMA_SA_PCPU attribute when creating
a state (via NEWSA or ALLOCSPI). Add a "pcpu-num" argument, and print
XFRMA_SA_PCPU when the kernel provides it.
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: David Ahern <dsahern@kernel.org>
netshaper fails to build from sources with this error:
$ make
netshaper
CC netshaper.o
LINK netshaper
/usr/bin/ld: ../lib/libutil.a(utils_math.o): in function `get_rate':
utils_math.c:(.text+0x97): undefined reference to `floor'
/usr/bin/ld: ../lib/libutil.a(utils_math.o): in function `get_size64':
utils_math.c:(.text+0x2a8): undefined reference to `floor'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:10: netshaper] Error 1
make: *** [Makefile:81: all] Error 2
Fix this simply linking against the math C library, similarly to what we
already did with commit 1a22ad2721fb ("build: Fix link errors on some
systems").
Fixes: 6f7779ad4ef6 ("netshaper: Add netshaper command")
Signed-off-by: Andrea Claudi <aclaudi@redhat.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Currently, devlink silently exits when a non-existent device is specified
for flashing or when the user lacks sufficient permissions. This makes it
hard to diagnose the problem.
Print an appropriate error message in these cases to improve user feedback.
Prior:
$ devlink dev flash foo/bar file test
$ sudo devlink dev flash foo/bar file test
$
After patch:
$ devlink/devlink dev flash foo/bar file test
devlink answers: Operation not permitted
$ sudo devlink/devlink dev flash foo/bar file test
devlink answers: No such device
Fixes: 9b13cddfe268 ("devlink: implement flash status monitoring")
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Replace the low-level json_writer API calls with the high-level
json_print API to maintain consistency with the rest of the iproute2
codebase.
Signed-off-by: Andrea Claudi <aclaudi@redhat.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
Replace the low-level json_writer API calls with the high-level
json_print API to maintain consistency with the rest of the iproute2
codebase.
Signed-off-by: Andrea Claudi <aclaudi@redhat.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
Replace the low-level json_writer API calls with the high-level
json_print API to maintain consistency with the rest of the iproute2
codebase.
Signed-off-by: Andrea Claudi <aclaudi@redhat.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
This reverts commit 14749b22dd8f2246511c6622c2a4646adfc5b184.
Only kernel can create implicit endpoints.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
ip mptcp supports the implicit flag since commit 3a2535a41854 ("mptcp:
add support for implicit flag"), however this flag is not listed in the
command inline help.
Add the implicit flag to the inline help.
Signed-off-by: Andrea Claudi <aclaudi@redhat.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
The ieee_maxrate UAPI is defined as kbps, but dcb_maxrate uses Bps.
This fix patch converts Bps to kbps for parse by dividing 125,
and convert kbps to Bps for print_rate() by multiplying 125.
Fixes: 117939d9bd89 ("dcb: Add a subtool for the DCB maxrate object")
Signed-off-by: Yijing Zeng <yijingzeng@meta.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Add support for the netshaper Generic Netlink family to
iproute2. Introduce a new command for configuring netshaper
parameters directly from userspace.
This interface allows users to set shaping attributes which
are passed to the kernel to perform the corresponding netshaper
operation.
Example usage:
$netshaper { set | show | delete } dev DEV \
handle scope SCOPE [id ID] \
[ bw-max BW_MAX ]
Internally, this triggers a kernel call to apply the shaping
configuration to the specified network device.
Currently, the tool supports the following functionalities:
- Setting bandwidth in Mbps, enabling bandwidth clamping for
a network device that support netshaper operations.
- Deleting the current configuration.
- Querying the existing configuration.
Additional netshaper operations will be integrated into the tool
as per requirement.
This change enables easy and scriptable configuration of bandwidth
shaping for devices that use the netshaper Netlink family.
Corresponding net-next patches:
1) https://lore.kernel.org/all/cover.1728460186.git.pabeni@redhat.com/
2) https://lore.kernel.org/lkml/1750144656-2021-1-git-send-email-ernis@linux.microsoft.com/
Install pkg-config and libmnl* packages to print kernel extack
errors to stdout.
Signed-off-by: Erni Sri Satya Vennela <ernis@linux.microsoft.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
