This patch fixes a problem with the libbpf version comparison to decide
if ENABLE_BPF_SKSTORAGE_SUPPORT could be enabled.
- The code enabled by ENABLE_BPF_SKSTORAGE_SUPPORT uses the function
btf_dump__new with an API that was introduced in libbpf 0.6.0. So
check now against libbpf version to be >= 0.6.x instead of 0.5.x.
- This code still depends on the necessity to have LIBBPF_MAJOR_VERSION
and LIBBPF_MINOR_VERSION defined, even if libbpf_version.h is not
present in the library development package. This was ensured with
the previous patch for the configure script.
Fixes: e3ecf048 ("ss: pretty-print BPF socket-local storage")
Signed-off-by: Stefan Mätje <stefan.maetje@esd.eu>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Old libbpf library versions (< 0.7.x) may not have the libbpf_version.h
header packaged. This header would provide LIBBPF_MAJOR_VERSION and
LIBBPF_MINOR_VERSION which are then missing to control conditional
compilation in some source files.
Provide surrogates for these defines via CFLAGS that are derived from
the LIBBPF_VERSION determined with $(${PKG_CONFIG} libbpf --modversion).
Signed-off-by: Stefan Mätje <stefan.maetje@esd.eu>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Reformat tc-cake to use man format (nroff) instead of pre-formatting.
Signed-off-by: Lương Việt Hoàng <tcm4095@gmail.com>
Acked-by: Toke Høiland-Jørgensen <toke@kernel.org>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Linux kernel commit 7298de9cd7255a783ba ("sch_cake: Add ingress mode") added
an ingress mode for CAKE, which can be enabled with the 'ingress' parameter.
Document the changes in CAKE's behavior when ingress mode is enabled.
Signed-off-by: Lương Việt Hoàng <tcm4095@gmail.com>
Reviewed-by: Toke Høiland-Jørgensen <toke@kernel.org>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Instead of pre-formatted bullet list, use the man macros.
Make sure same sentence format is used in all options.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
The man page had a dangling quote character in the usage text
which can confuse auto-color/format code like Emacs and Vim.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Print also the peer policy, example:
$ ip -d l sh dev netkit0
...
netkit mode l2 type primary policy blackhole peer policy forward
...
Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: David Ahern <dsahern@kernel.org>
include/utils.h already provides textify(), which is functionally
equivalent to __stringify().
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
extend TC flower for matching on tunnel metadata.
Changes since v2:
- split uAPI changes and TC code in separate patches, as per David's request [2]
Changes since v1:
- fix incostintent naming in explain() and in tc-flower.8 (Asbjørn)
Changes since RFC:
- update uAPI bits to Asbjørn's most recent code [1]
- add 'tun' prefix to all flag names (Asbjørn)
- allow parsing 'enc_flags' multiple times, without clearing the match
mask every time, like happens for 'ip_flags' (Asbjørn)
- don't use "matches()" for parsing argv[] (Stephen)
- (hopefully) improve usage() printout (Asbjørn)
- update man page
[1] https://lore.kernel.org/netdev/20240709163825.1210046-1-ast@fiberby.net/
[2] https://lore.kernel.org/netdev/cc73004c-9aa8-9cd3-b46e-443c0727c34d@kernel.org/
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
Adding an endpoint with 'id 0' is not allowed. In this case, the kernel
will ignore this 'id 0' and set another one.
Similarly, because there are no endpoints with this 'id 0', changing an
attribute for such endpoint will not be possible.
To avoid some confusions, it sounds better to clearly report an error
that the ID cannot be 0 in these cases.
Acked-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Explain the range (u8), and the special case for ID 0.
The endpoints here are for all the connections, while the ID 0 is a
special case per connection, depending on the source address used by the
initial subflow. This ID 0 can then not be used for the global
endpoints.
Acked-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
'fullmesh' affects the subflow creation, it has to be used with the
'subflow' flag. That's what is enforced on the kernel side.
Acked-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
That's the behaviour with the default packet scheduler.
In some early design, the default scheduler was supposed to take into
account only the received backup flags, but it ended up not being the
case, and setting the flag would also affect outgoing data.
Suggested-by: Mat Martineau <martineau@kernel.org>
Acked-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
That's what is enforced by the kernel: the 'port' is used to create a
new listening socket on that port, not to create a new subflow from/to
that port. It then requires the 'signal' flag.
Acked-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
According to some bug reports on the MPTCP project, these options might
be a bit confusing for some.
Mentioning that the 'signal' flag is typically for a server, and the
'subflow' one is typically for a client should help the user knowing in
which context which flag should be picked.
Acked-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
It was missing, while it is a very important option.
Indeed, without it, the kernel might not pick the right interface to
send packets for additional subflows. Mention that in the man page.
Acked-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
The ip address man page had some small things that needed update:
- ip address delete without address returns not supported
- always use full words for commands in man pages
(ie "delete" not "del")
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
When running "ip monitor", accept_msg() first prints the prefix and
then calls the object-specific print function, which also does the
filtering. Therefore, it is possible that the prefix is printed even
for events that get ignored later. For example:
ip link add dummy1 type dummy
ip link set dummy1 up
ip -ts monitor all dev dummy1 &
ip link add dummy2 type dummy
ip addr add dev dummy1 192.0.2.1/24
generates:
[2024-07-12T22:11:26.338342] [LINK][2024-07-12T22:11:26.339846] [ADDR]314: dummy1 inet 192.0.2.1/24 scope global dummy1
valid_lft forever preferred_lft forever
Fix this by printing the prefix only after the filtering. Now the
output for the commands above is:
[2024-07-12T22:11:26.339846] [ADDR]314: dummy1 inet 192.0.2.1/24 scope global dummy1
valid_lft forever preferred_lft forever
See also commit 7e0a889b54 ("bridge: Do not print stray prefixes in
monitor mode") which fixed the same problem in the bridge tool.
Signed-off-by: Beniamino Galvani <b.galvani@gmail.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Expression 'ttl & ~(255 >> 0)' is always zero, because right operand
has 8 trailing zero bits, which is greater or equal than the size
of the left operand == 8 bits.
Found by RASU JSC.
Signed-off-by: Maks Mishin <maks.mishinFZ@gmail.com>
Reviewed-by: Guillaume Nault <gnault@redhat.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Add missing "size" and "path" words in the example, as the current example
is incorrect and will be rejected by the command.
The keywords were missing from very inception of devlink-resource man page
Fixes: 58b48c5d75 ("devlink: Update man pages and add resource man")
Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Michal Kubiak <michal.kubiak@intel.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Allow a port's spanning tree state to be modified on a per-MSTI basis,
and support dumping the current MST states for every port and MSTI.
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
Allow the user to associate one or more VLANs with a multiple spanning
tree instance (MSTI), when MST is enabled on the bridge.
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Reviewed-by: Hangbin Liu <liuhangbin@gmail.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: David Ahern <dsahern@kernel.org>
When enabled, the bridge's legacy per-VLAN STP facility is replaced
with the Multiple Spanning Tree Protocol (MSTP) compatible version.
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Reviewed-by: Hangbin Liu <liuhangbin@gmail.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: David Ahern <dsahern@kernel.org>
Print all of the missing parameters, also in the presence of unknown ones.
Take for example a correct command:
$ devlink resource set pci/0000:01:00.0 path /kvd/linear size 98304
And remove the "size" keyword:
$ devlink resource set pci/0000:01:00.0 path /kvd/linear 98304
That yields output:
Resource size expected.
Unknown option "98304"
Prior to the patch only the last line of output was present. And if user
would forgot also the "path" keyword, there will be additional line:
Resource path expected.
in the stderr.
Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Michal Kubiak <michal.kubiak@intel.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
This patch adds a new device attribute "type", as well as supports to
add and delete a rdma device with a specific type. This new device
provides a subset of functionalists defined in IBTA spec.
Currently only type "SMI" is supported: A SMI device provides SMI (QP0)
interface; This device and it's parent associates with the same HCA port
and shares the physical link, so when the parent doesn't support SMI,
It allows the subnet manager to configure the link.
This patch also supports to print device type and parent if any.
Examples:
$ rdma dev add smi1 type SMI parent ibp8s0f1
$ rdma dev show smi1
2: smi1: node_type ca fw 20.38.1002 node_guid 9803:9b03:009f:d5ef sys_image_guid 9803:9b03:009f:d5ee type smi parent ibp8s0f1
$ rdma dev del smi1
Signed-off-by: Mark Zhang <markzhang@nvidia.com>
Acked-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: David Ahern <dsahern@kernel.org>
Update rdma_netlink.h file upto kernel commit 294424839b5e
("RDMA/nldev: Add support to dump device type and parent device if exists")
Signed-off-by: Mark Zhang <markzhang@nvidia.com>
Acked-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: David Ahern <dsahern@kernel.org>
The ip route command would silently hide multipath routes when filter
by interface. The problem was it was not looking for interface when
filter multipath routes.
Example:
ip link add name dummy1 up type dummy
ip link add name dummy2 up type dummy
ip address add 192.0.2.1/28 dev dummy1
ip address add 192.0.2.17/28 dev dummy2
ip route add 198.51.100.0/24 \
nexthop via 192.0.2.2 dev dummy1 \
nexthop via 192.0.2.18 dev dummy2
Before:
ip route show dev dummy1
192.0.2.0/28 proto kernel scope link src 192.0.2.1
After:
ip route show dev dummy1
192.0.2.0/28 proto kernel scope link src 192.0.2.1
198.51.100.0/24
nexthop via 192.0.2.2 dev dummy1 weight 1
nexthop via 192.0.2.18 dev dummy2 weight 1
Reported-by: "Muggeridge, Matt" <matt.muggeridge2@hpe.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Clang complains that format string is not a string literal
unless the functions are annotated.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
dl_opts_put() function missed to consider IO eqs option flag.
Due to this, when max_io_eqs setting is applied only when it
is combined with other attributes such as roce/hw_addr.
When max_io_eqs is the only attribute set, it missed to
apply the attribute.
Fix it by adding the missing flag.
Fixes: e8add23c59 ("devlink: Support setting max_io_eqs")
Signed-off-by: Parav Pandit <parav@nvidia.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Use the COLUMNS environment variable [1] when determining the screen width,
if using TIOCGWINSZ isn't possible or if it fails. This allows better use
of the available horizontal screen space in certain scenarios, and makes
the produced outputs more readable, as described further below.
All major shells can maintain the COLUMNS variable according to the current
screen size, [2][3][4] but this shell variable isn't actually an environment
variable, i.e. it doesn't get exported to the shell subprocesses by default.
For example, no COLUMNS environment variable reaches ss(8) when it's executed
as part of a shell pipeline or inside a shell script.
Though, users can opt to export the COLUMNS variable by hand, or they can
rely on some other utilities to do that for them. A good example of such
utilities is watch(1) that exports COLUMNS as an environment variable to
the processes it executes. [5] Using ss(8) together with watch(1) is rather
useful, and honoring the exported COLUMNS variable makes the outputs produced
by ss(8) in this scenario more readable.
The behavior of shells, which don't export the COLUMNS variable by default,
makes this change safe in the sense of not affecting the usual shell pipeline
workflows or various shell scripts that use ss(8).
[1] https://pubs.opengroup.org/onlinepubs/9699919799.2016edition/basedefs/V1_chap08.html
[2] https://man.archlinux.org/man/bash.1.en#COLUMNS
[3] https://man.archlinux.org/man/tcsh.1.en#Terminal_management_(+)
[4] https://man.archlinux.org/man/zshall.1.en#Configuration
[5] https://gitlab.com/procps-ng/procps/-/blob/master/NEWS?ref_type=heads#L623
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
Signed-off-by: David Ahern <dsahern@kernel.org>
Also update the man page accordingly, and add ip-monitor to see also
Signed-off-by: Yedaya Katsman <yedaya.ka@gmail.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
On glibc based systems the definition of 'struct timeval' is pulled in
with inclusion of <stdlib.h> header, but on musl based systems it
doesn't work this way. Missing definition triggers an
incompatible-pointer-types error with gcc 14 (warning on previous
versions of gcc):
../include/json_print.h:80:30: warning: 'struct timeval' declared inside parameter list will not be visible outside of this definition or declaration
80 | _PRINT_FUNC(tv, const struct timeval *)
| ^~~~~~~
../include/json_print.h:50:37: note: in definition of macro '_PRINT_FUNC'
50 | type value); \
| ^~~~
../include/json_print.h:80:30: warning: 'struct timeval' declared inside parameter list will not be visible outside of this definition or declaration
80 | _PRINT_FUNC(tv, const struct timeval *)
| ^~~~~~~
../include/json_print.h:55:45: note: in definition of macro '_PRINT_FUNC'
55 | type value) \
| ^~~~
../include/json_print.h: In function 'print_tv':
../include/json_print.h:58:48: error: passing argument 5 of 'print_color_tv' from incompatible pointer type [-Wincompatible-pointer-types]
58 | value); \
| ^~~~~
| |
| const struct timeval *
Signed-off-by: Gabi Falk <gabifalk@gmx.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
The "as", "to", "connected" and "notify" options were missing from the
help message in the route get section. Add them to usage help and man
page.
Note that there isn't an explanation for "as" or "notify" in the man
page.
Signed-off-by: Yedaya Katsman <yedaya.ka@gmail.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
