Vincent Mailhol [Wed, 3 Dec 2025 18:24:34 +0000 (19:24 +0100)]
iplink_can: add CAN XL TMS PWM configuration support
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.
Vincent Mailhol [Wed, 3 Dec 2025 18:24:33 +0000 (19:24 +0100)]
iplink_can: add CAN XL transceiver mode setting (TMS) support
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>
Vincent Mailhol [Wed, 3 Dec 2025 18:24:32 +0000 (19:24 +0100)]
iplink_can: add initial CAN XL support
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.
Vincent Mailhol [Wed, 3 Dec 2025 18:24:31 +0000 (19:24 +0100)]
iplink_can: add RESTRICTED operation mode support
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>
Vincent Mailhol [Wed, 3 Dec 2025 18:24:30 +0000 (19:24 +0100)]
iplink_can: print_usage: describe the CAN bittiming units
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>
Vincent Mailhol [Wed, 3 Dec 2025 18:24:29 +0000 (19:24 +0100)]
iplink_can: print_usage: change unit for minimum time quanta to mtq
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>
Vincent Mailhol [Wed, 3 Dec 2025 18:24:28 +0000 (19:24 +0100)]
iplink_can: print_usage: fix the text indentation
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>
Akhilesh Nema [Wed, 3 Dec 2025 02:11:24 +0000 (18:11 -0800)]
fix 'UINT_MAX' undeclared with build with musl libc
- 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>
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".
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.
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.
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>
David Ahern [Fri, 21 Nov 2025 16:12:27 +0000 (09:12 -0700)]
Merge branch 'dpll' into next
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.
Petr Oros [Tue, 18 Nov 2025 14:10:31 +0000 (15:10 +0100)]
dpll: Add dpll command
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.
- 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>
Saeed Mahameed [Fri, 7 Nov 2025 00:14:35 +0000 (16:14 -0800)]
devlink: Support DEVLINK_ESWITCH_MODE_SWITCHDEV_INACTIVE
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
Ivan Vecera [Thu, 30 Oct 2025 19:42:00 +0000 (20:42 +0100)]
devlink: Add support for 64bit parameters
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>
Sabrina Dubroca [Wed, 29 Oct 2025 11:06:16 +0000 (12:06 +0100)]
ip-xfrm: add pcpu-num support
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>
Andrea Claudi [Tue, 28 Oct 2025 22:17:56 +0000 (23:17 +0100)]
netshaper: fix build failure
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>
Ivan Vecera [Wed, 22 Oct 2025 12:23:02 +0000 (14:23 +0200)]
devlink: fix devlink flash error reporting
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>
Andrea Claudi [Tue, 21 Oct 2025 19:26:56 +0000 (21:26 +0200)]
mptcp: add implicit flag to the 'ip mptcp' inline help
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>
Yijing Zeng [Sat, 11 Oct 2025 22:25:24 +0000 (15:25 -0700)]
dcb: fix tc-maxrate unit conversions
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.
Yureka [Sun, 12 Oct 2025 12:39:47 +0000 (14:39 +0200)]
lib: bridge: avoid redefinition of in6_addr
On musl libc, which does not use the kernel definitions of in6_addr, including
the libc headers after the kernel (UAPI) headers would cause a redefinition
error. The opposite order avoids the redefinition.
Fixes: 9e89d5b94d749f37525cd8778311e1c9f28f172a Signed-off-by: Yureka <yureka@cyberchaos.dev> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Shahar Shitrit [Wed, 8 Oct 2025 06:57:18 +0000 (09:57 +0300)]
devlink: Introduce burst period for health reporter
Add a new devlink health set option to configure the health
reporter’s burst period. The burst period defines a time window
during which recovery attempts for reported errors are allowed.
Once this period expires, the configured grace period begins.
This feature addresses cases where multiple errors occur
simultaneously due to a common root cause. Without a burst period,
the grace period starts immediately after the first error recovery
attempt finishes. This means that only the first error might be
recovered, while subsequent errors are blocked during the grace period.
With the burst period, the reporter initiates a recovery attempt for
every error reported within this time window before the grace period
starts.
Example:
$ devlink health set pci/0000:00:09.0 reporter tx burst_period 500
Signed-off-by: Shahar Shitrit <shshitrit@nvidia.com> Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: David Ahern <dsahern@kernel.org>
Yureka [Sun, 12 Oct 2025 12:39:47 +0000 (14:39 +0200)]
lib: bridge: avoid redefinition of in6_addr
On musl libc, which does not use the kernel definitions of in6_addr, including
the libc headers after the kernel (UAPI) headers would cause a redefinition
error. The opposite order avoids the redefinition.
This option has no effect in modes other than 802.3ad mode.
When this option enabled, the bond device will broadcast ARP/ND
packets to all active slaves.
Signed-off-by: Tonghao Zhang <tonghao@bamaicloud.com> Reviewed-by: Hangbin Liu <liuhangbin@gmail.com> Cc: Stephen Hemminger <stephen@networkplumber.org> Cc: David Ahern <dsahern@gmail.com> Cc: Hangbin Liu <liuhangbin@gmail.com> Signed-off-by: David Ahern <dsahern@kernel.org>
Andrea Claudi [Wed, 3 Sep 2025 07:44:56 +0000 (09:44 +0200)]
tc: gred: fix debug print
When build with -DDEBUG, tc build fails with:
q_gred.c: In function ‘init_gred’:
q_gred.c:53:17: error: passing argument 2 of ‘fprintf’ from incompatible pointer type [-Wincompatible-pointer-types]
53 | DPRINTF(stderr, "init_gred: invoked with %s\n", *argv);
| ^~~~~~~
| |
| FILE *
This is due to the DPRINTF macro call. Indeed DPRINTF is defined as a
two-args macro when -DDEBUG is used, while it uses 3 args in this call.
Fix it simply dropping the useless first arg.
Fixes: aba5acdfdb34 ("(Logical change 1.3)") Signed-off-by: Andrea Claudi <aclaudi@redhat.com> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Eric Biggers [Sun, 24 Aug 2025 01:47:21 +0000 (21:47 -0400)]
man8: ip-sr: Document that passphrase must be high-entropy
'ip sr hmac set' takes a newline-terminated "passphrase", but it fails
to stretch it. The "passphrase" actually gets used directly as the key.
This makes it difficult to use securely.
I recommend deprecating this command and replacing it with a command
that either stretches the passphrase or explicitly takes a key instead
of a passphrase. But for now, let's at least document this pitfall.
Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Chia-Yu Chang [Mon, 4 Aug 2025 12:20:19 +0000 (14:20 +0200)]
tc: add dualpi2 scheduler module
DUALPI2 AQM is a combination of the DUALQ Coupled-AQM with a PI2
base-AQM. The PI2 AQM is in turn both an extension and a simplification
of the PIE AQM. PI2 makes quite some PIE heuristics unnecessary, while
being able to control scalable congestion controls like TCP-Prague.
With PI2, both Reno/Cubic can be used in parallel with Prague,
maintaining window fairness. DUALQ provides latency separation between
low latency Prague flows and Reno/Cubic flows that need a bigger queue.
This patch adds support to tc to configure it through its netlink
interface.
Signed-off-by: Chia-Yu Chang <chia-yu.chang@nokia-bell-labs.com> Co-developed-by: Olga Albisser <olga@albisser.org> Signed-off-by: Olga Albisser <olga@albisser.org> Co-developed-by: Koen De Schepper <koen.de_schepper@nokia-bell-labs.com> Signed-off-by: Koen De Schepper <koen.de_schepper@nokia-bell-labs.com> Co-developed-by: Oliver Tilmans <olivier.tilmans@nokia.com> Signed-off-by: Oliver Tilmans <olivier.tilmans@nokia.com> Signed-off-by: Bob Briscoe <research@bobbriscoe.net> Co-developed-by: Henrik Steen <henrist@henrist.net> Signed-off-by: Henrik Steen <henrist@henrist.net> Reviewed-by: Alok Tiwari <alok.a.tiwari@oracle.com> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
David Ahern [Thu, 18 Sep 2025 02:19:06 +0000 (02:19 +0000)]
Merge branch 'tc-police-64b-burst' into next
Jay Vosburgh says:
====================
In summary, this patchset changes the user space handling of the
tc police burst parameter to permit burst sizes that exceed 4 GB when the
specified rate is high enough that the kernel API for burst can accomodate
such.
Additionally, if the burst exceeds the upper limit of the kernel
API, this is now flagged as an error. The existing behavior silently
overflows, resulting in arbitrary values passed to the kernel.
In detail, as presently implemented, the tc police burst option
limits the size of the burst to to 4 GB, i.e., UINT_MAX for a 32 bit
unsigned int. This is a reasonable limit for the low rates common when
this was developed. However, the underlying implementation of burst is
computed as "time at the specified rate," and for higher rates, a burst
size exceeding 4 GB is feasible without modification to the kernel.
The burst size provided on the command line is translated into a
duration, representing how much time is required at the specified rate to
transmit the given burst size.
This time is calculated in units of "psched ticks," each of which
is 64 nsec[0]. The computed number of psched ticks is sent to the kernel
as a __u32 value.
Because burst is ultimately calculated as a time duration, the
real upper limit for a burst is UINT_MAX psched ticks, i.e.,
Thus, the burst size at 5Mbit/sec is limited by the __u32 size of
the psched tick field in the kernel API, not the 4 GB limit of the tc
police burst user space API.
However, at higher rates, e.g., 10 Gbit/sec, the burst size is
currently limited by the 4 GB maximum for the burst command line parameter
value, rather than UINT_MAX psched ticks:
So, at higher rates, burst sizes exceeding 4 GB are both
reasonable and feasible, up to the UINT_MAX limit for psched ticks.
Enabling this requires changes only to the user space processing of the
burst size parameter in tc.
In principle, the other packet schedulers utilizing psched ticks
for burst sizing, htb and tbf, could be similarly changed to permit larger
burst sizes, but this patch set does not do so.
Separately, for the burst duration calculation overflow (i.e.,
that the number of psched ticks exceeds UINT_MAX), under the current
implementation, one example of overflow is as follows:
# /sbin/tc filter add dev eth0 protocol ip prio 1 parent ffff: handle 1 fw police rate 1Mbit peakrate 10Gbit burst 34375000 mtu 64Kb conform-exceed reclassify
# /sbin/tc -raw filter get dev eth0 ingress protocol ip pref 1 handle 1 fw
filter ingress protocol ip pref 1 fw chain 0 handle 0x1 police 0x1 rate 1Mbit burst 15261b mtu 64Kb [001d1bf8] peakrate 10Gbit action reclassify overhead 0b
ref 1 bind 1
Note that the returned burst value is 15261b, which does not match
the supplied value of 34375000. With this patch set applied, this
situation is flagged as an error.
[0] psched ticks are defined in the kernel in include/net/pkt_sched.h:
These values are exported to user space via /proc/net/psched, the
second field being PSCHED_TICKS2NS(1), which at present is 64 (0x40). tc
uses this value to compute its internal "tick_in_usec" variable containing
the number of psched ticks per usec (15.625) used for the psched tick
computations.
Lastly, note that PSCHED_SHIFT was previously 10, and changed to 6
in commit a4a710c4a7490 in 2009. I have not tested backwards
compatibility of these changes with kernels of that era.
Jay Vosburgh [Tue, 16 Sep 2025 21:57:31 +0000 (14:57 -0700)]
tc/police: enable use of 64 bit burst parameter
Modify tc police to permit burst sizes up to the limit of the
kernel API, which may exceed 4 GB of burst size at higher rates.
As presently implemented, the tc police burst option limits the
size of the burst to 4 GB in size. This is a reasonable limit for the
rates common when this was developed. However, the underlying
implementation of burst is expressed in terms of time at the specified
rate, and for higher rates, a burst size exceeding 4 GB is feasible
without modification to the kernel.
The kernel API specifies the burst size as the number of "psched
ticks" needed to send the burst at the specified rate. As each psched
tick is 64 nsec, the actual kernel limit on burst size is approximately
274.88 seconds (UINT_MAX * 64 / NSEC_PER_SEC).
For example, at a rate of 10 Gbit/sec, the current 4 GB size limit
corresponds to just under 3.5 seconds.
Additionally, overflows (burst values that exceed UINT_MAX psched
ticks) are now correctly detected, and flagged as an error, rather than
passing arbitrary psched tick values to the kernel.
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: Jay Vosburgh <jay.vosburgh@canonical.com> Signed-off-by: David Ahern <dsahern@kernel.org>
Jay Vosburgh [Tue, 16 Sep 2025 21:57:30 +0000 (14:57 -0700)]
tc: Expand tc_calc_xmittime, tc_calc_xmitsize to u64
In preparation for accepting 64-bit burst sizes, modify
tc_calc_xmittime and tc_calc_xmitsize to handle 64-bit values.
tc_calc_xmittime continues to return a 32-bit value, as its range
is limited by the kernel API, but overflow is now detected and the return
value is limited to UINT_MAX.
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: Jay Vosburgh <jay.vosburgh@canonical.com> Signed-off-by: David Ahern <dsahern@kernel.org>
Jay Vosburgh [Tue, 16 Sep 2025 21:57:29 +0000 (14:57 -0700)]
tc: Add get_size64 and get_size64_and_cell
In preparation for accepting 64 bit burst sizes, create 64-bit
versions of get_size and get_size_and_cell. The 32-bit versions become
wrappers around the 64-bit versions.
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: Jay Vosburgh <jay.vosburgh@canonical.com> Signed-off-by: David Ahern <dsahern@kernel.org>
Jay Vosburgh [Tue, 16 Sep 2025 21:57:28 +0000 (14:57 -0700)]
lib: Update backend of print_size to accept 64 bit size
In preparation for accepting 64 bit burst sizes, modify
sprint_size, the formatting function behind print_size, to accept __u64 as
its size parameter. Also include a "Gb" size category.
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: Jay Vosburgh <jay.vosburgh@canonical.com> Signed-off-by: David Ahern <dsahern@kernel.org>
Hangbin Liu [Tue, 2 Sep 2025 06:47:38 +0000 (06:47 +0000)]
iplink: bond_slave: add support for actor_port_prio
Add support for the actor_port_prio option for bond slaves.
This per-port priority can be used by the bonding driver in ad_select to
choose the higher-priority aggregator during failover.
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Signed-off-by: David Ahern <dsahern@kernel.org>
Add a script to automate importing Linux UAPI headers from kernel source.
The script handles dependency resolution and creates a commit with proper
attribution, similar to the ethtool project approach.
Andrea Claudi [Wed, 3 Sep 2025 07:44:56 +0000 (09:44 +0200)]
tc: gred: fix debug print
When build with -DDEBUG, tc build fails with:
q_gred.c: In function ‘init_gred’:
q_gred.c:53:17: error: passing argument 2 of ‘fprintf’ from incompatible pointer type [-Wincompatible-pointer-types]
53 | DPRINTF(stderr, "init_gred: invoked with %s\n", *argv);
| ^~~~~~~
| |
| FILE *
This is due to the DPRINTF macro call. Indeed DPRINTF is defined as a
two-args macro when -DDEBUG is used, while it uses 3 args in this call.
Fix it simply dropping the useless first arg.
Fixes: aba5acdfdb34 ("(Logical change 1.3)") Signed-off-by: Andrea Claudi <aclaudi@redhat.com>
Eric Biggers [Sun, 24 Aug 2025 01:47:21 +0000 (21:47 -0400)]
man8: ip-sr: Document that passphrase must be high-entropy
'ip sr hmac set' takes a newline-terminated "passphrase", but it fails
to stretch it. The "passphrase" actually gets used directly as the key.
This makes it difficult to use securely.
I recommend deprecating this command and replacing it with a command
that either stretches the passphrase or explicitly takes a key instead
of a passphrase. But for now, let's at least document this pitfall.
Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Chia-Yu Chang [Mon, 4 Aug 2025 12:20:19 +0000 (14:20 +0200)]
tc: add dualpi2 scheduler module
DUALPI2 AQM is a combination of the DUALQ Coupled-AQM with a PI2
base-AQM. The PI2 AQM is in turn both an extension and a simplification
of the PIE AQM. PI2 makes quite some PIE heuristics unnecessary, while
being able to control scalable congestion controls like TCP-Prague.
With PI2, both Reno/Cubic can be used in parallel with Prague,
maintaining window fairness. DUALQ provides latency separation between
low latency Prague flows and Reno/Cubic flows that need a bigger queue.
This patch adds support to tc to configure it through its netlink
interface.
Signed-off-by: Chia-Yu Chang <chia-yu.chang@nokia-bell-labs.com> Co-developed-by: Olga Albisser <olga@albisser.org> Signed-off-by: Olga Albisser <olga@albisser.org> Co-developed-by: Koen De Schepper <koen.de_schepper@nokia-bell-labs.com> Signed-off-by: Koen De Schepper <koen.de_schepper@nokia-bell-labs.com> Co-developed-by: Oliver Tilmans <olivier.tilmans@nokia.com> Signed-off-by: Oliver Tilmans <olivier.tilmans@nokia.com> Signed-off-by: Bob Briscoe <research@bobbriscoe.net> Co-developed-by: Henrik Steen <henrist@henrist.net> Signed-off-by: Henrik Steen <henrist@henrist.net> Reviewed-by: Alok Tiwari <alok.a.tiwari@oracle.com>
Anton Moryakov [Sun, 20 Jul 2025 15:38:43 +0000 (18:38 +0300)]
ip: ipmaddr.c: Fix possible integer underflow in read_igmp()
Static analyzer pointed out a potential error:
Possible integer underflow: left operand is tainted. An integer underflow
may occur due to arithmetic operation (unsigned subtraction) between variable
'len' and value '1', when 'len' is tainted { [0, 18446744073709551615] }
The fix adds a check for 'len == 0' before accessing the last character of
the name, and skips the current line in such cases to avoid the underflow.
Reported-by: SVACE static analyzer Signed-off-by: Anton Moryakov <ant.v.moryakov@gmail.com> Signed-off-by: David Ahern <dsahern@kernel.org>
Anton Moryakov [Sat, 19 Jul 2025 10:42:12 +0000 (13:42 +0300)]
misc: fix memory leak in ifstat.c
A memory leak was detected by the static analyzer SVACE in the function
get_nlmsg_extended(). The issue occurred when parsing extended interface
statistics failed due to a missing nested attribute. In this case,
memory allocated for 'n->name' via strdup() was not freed before returning,
resulting in a leak.
The fix adds an explicit 'free(n->name)' call before freeing the containing
structure in the error path.
Reported-by: SVACE static analyzer Signed-off-by: Anton Moryakov <ant.v.moryakov@gmail.com> Signed-off-by: David Ahern <dsahern@kernel.org>
Anton Moryakov [Sat, 19 Jul 2025 16:31:22 +0000 (19:31 +0300)]
misc: ss.c: fix logical error in main function
In the line if (!dump_tcpdiag) { there was a logical error
in checking the descriptor, which the static analyzer complained
about (this action is always false)
fixed by replacing !dump_tcpdiag with !dump_fp
Reported-by: SVACE static analyzer Signed-off-by: Anton Moryakov <ant.v.moryakov@gmail.com> Acked-by: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: David Ahern <dsahern@kernel.org>
bridge: fdb: Add support for FDB activity notification control
Add support for FDB activity notification control [1].
Users can use this to enable activity notifications on a new FDB entry
that was learned on an ES (Ethernet Segment) peer and mark it as locally
inactive:
The "norefresh" keyword is used to avoid resetting the entry's last
active time (i.e., "updated" time).
User space will receive a notification when the entry becomes inactive
and the control plane will be able to mark the entry as locally
inactive. Note that the entry was converted from a dynamic entry to a
static entry to prevent the kernel from automatically deleting it upon
inactivity.
An existing inactive entry can only be marked as active by the kernel or
by disabling and enabling activity notifications:
$ bridge -d fdb get 00:11:22:33:44:55 br br1
00:11:22:33:44:55 dev bond1 activity_notify inactive master br1 static
# bridge fdb replace 00:11:22:33:44:55 dev bond1 master static activity_notify
$ bridge -d fdb get 00:11:22:33:44:55 br br1
00:11:22:33:44:55 dev bond1 activity_notify inactive master br1 static
# bridge fdb replace 00:11:22:33:44:55 dev bond1 master static
# bridge fdb replace 00:11:22:33:44:55 dev bond1 master static activity_notify
$ bridge -d fdb get 00:11:22:33:44:55 br br1
00:11:22:33:44:55 dev bond1 activity_notify master br1 static
Marking an entry as inactive while activity notifications are disabled
does not make sense and will be rejected by the kernel:
Kernel commit 1bbdb81a9836 ("devlink: Fix excessive stack usage in rate TC bandwidth parsing")
introduced a dedicated attribute set (DEVLINK_RATE_TC_ATTR_*) for entries nested
under DEVLINK_ATTR_RATE_TC_BWS.
Update the parser to reflect this change by validating the nested
attributes and sync the UAPI header to include the changes.
Fixes: c83d1477f8b2 ("Add support for 'tc-bw' attribute in devlink-rate") Signed-off-by: Carolina Jubran <cjubran@nvidia.com> Signed-off-by: David Ahern <dsahern@kernel.org>
Introduce a new attribute 'tc-bw' to devlink-rate, allowing users to
set the bandwidth allocation per traffic class. The new attribute
enables fine-grained QoS configurations by assigning relative bandwidth
shares to each traffic class, supporting more precise traffic shaping,
which helps in achieving more precise bandwidth management across
traffic streams.
Add support for configuring 'tc-bw' via the devlink userspace utility
and parse the 'tc-bw' arguments for accurate bandwidth assignment per
traffic class.
This feature supports 8 traffic classes as defined by the IEEE 802.1Qaz
standard.
Example commands:
- devlink port function rate add pci/0000:08:00.0/group \
tx_share 10Gbit tx_max 50Gbit tc-bw 0:20 1:0 2:0 3:0 4:0 5:80 6:0 7:0
- devlink port function rate set pci/0000:08:00.0/group \
tc-bw 0:20 1:0 2:0 3:0 4:0 5:80 6:0 7:0
Add support for the recently added "extern_valid" flag that can be used
to indicate to the kernel that a neighbor entry was learned and
determined to be valid externally. The kernel will not remove or
invalidate the entry, but it can probe the entry and notify user space
when the entry becomes reachable. The kernel will return the entry to
stale state if it did not receive a confirmation after probing the
entry.
Example usage and output:
# ip neigh add 192.0.2.1 nud none dev br0.10 extern_valid
Error: Cannot create externally validated neighbor with an invalid state.
# ip neigh add 192.0.2.1 lladdr 00:11:22:33:44:55 nud stale dev br0.10 extern_valid
$ ip neigh show dev br0.10
192.0.2.1 lladdr 00:11:22:33:44:55 extern_valid STALE
$ ip -j -p neigh show dev br0.10
[ {
"dst": "192.0.2.1",
"lladdr": "00:11:22:33:44:55",
"extern_valid": null,
"state": [ "STALE" ]
} ]
Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David Ahern <dsahern@kernel.org>
David Ahern [Wed, 2 Jul 2025 14:36:20 +0000 (14:36 +0000)]
Merge branch 'bridge-mcast-state-vlan' into next
Fabian Pfitzner says:
====================
Dump the multicast querier state per vlan.
This commit is almost identical to [1].
The querier state can be seen with:
bridge -d vlan global
The options for vlan filtering and vlan mcast snooping have to be enabled
in order to see the output:
ip link set [dev] type bridge mcast_vlan_snooping 1 vlan_filtering 1
The querier state shows the following information for IPv4 and IPv6
respectively:
1) The ip address of the current querier in the network. This could be
ourselves or an external querier.
2) The port on which the querier was seen
3) Querier timeout in seconds
Fabian Pfitzner [Wed, 25 Jun 2025 08:39:14 +0000 (10:39 +0200)]
bridge: dump mcast querier per vlan
Dump the multicast querier state per vlan.
This commit is almost identical to [1].
The querier state can be seen with:
bridge -d vlan global
The options for vlan filtering and vlan mcast snooping have to be enabled
in order to see the output:
ip link set [dev] type bridge mcast_vlan_snooping 1 vlan_filtering 1
The querier state shows the following information for IPv4 and IPv6
respectively:
1) The ip address of the current querier in the network. This could be
ourselves or an external querier.
2) The port on which the querier was seen
3) Querier timeout in seconds
projects / thirdparty / iproute2.git / log
