In the following case:
union ct_addr {
unsigned int ipv4;
struct in6_addr ipv6;
};
union ct_addr zero_ip = {0};
The ipv6 field might not be properly initialized.
For instance, clang 18.1.1 does not initialize the ipv6 field.
Reported-at: https://issues.redhat.com/browse/FDP-608
Acked-by: Paolo Valerio <pvalerio@redhat.com>
Signed-off-by: Xavier Simonart <xsimonar@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
This change has no impact, since -Dmachine=default gets converted by
DPDK into -Dplatform=generic (since v21.08, see the link to DPDK commit
below). Yet, switch to explicitly setting -Dplatform and avoid the
following warning:
2024-04-18T14:50:16.8001092Z config/meson.build:113: WARNING: The
"machine" option is deprecated. Please use "cpu_instruction_set"
instead.
While at it, solve another warning and call explicitly meson setup.
2024-04-18T14:50:17.0770596Z WARNING: Running the setup command as
`meson [options]` instead of `meson setup [options]` is ambiguous
and deprecated.
Link: https://git.dpdk.org/dpdk/commit/?id=bf66003b51ec
Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Simon Horman <horms@ovn.org>
Help text for 'ovsdb-client dump' does not mention that it's capable
of dumping specific table's contents if user supplies table's name
as a third positional argument.
Signed-off-by: Martin Kalcok <martin.kalcok@canonical.com>
Signed-off-by: Simon Horman <horms@ovn.org>
While tracing NAT actions, pointer to the action may be stored in the
recirculation node for future reference. However, while translating
actions for the group bucket in xlate_group_bucket, the action list is
allocated temporarily on stack. So, in case the group translation
leads to NAT, the stack pointer can be stored in the recirculation node
and accessed later by the tracing mechanism when this stack memory is
long gone:
==396230==ERROR: AddressSanitizer: stack-use-after-return on address
0x191844 at pc 0x64222a bp 0xa5da10 sp 0xa5da08
READ of size 1 at 0x191844 thread T0
0 0x642229 in ofproto_trace_recirc_node ofproto/ofproto-dpif-trace.c:704:49
1 0x642229 in ofproto_trace ofproto/ofproto-dpif-trace.c:867:9
2 0x6434c1 in ofproto_unixctl_trace ofproto/ofproto-dpif-trace.c:489:9
3 0xc1e491 in process_command lib/unixctl.c:310:13
4 0xc1e491 in run_connection lib/unixctl.c:344:17
5 0xc1e491 in unixctl_server_run lib/unixctl.c:395:21
6 0x53eedf in main ovs/vswitchd/ovs-vswitchd.c:131:9
7 0x2be087 in __libc_start_call_main
8 0x2be14a in __libc_start_main@GLIBC_2.2.5
9 0x42dee4 in _start (vswitchd/ovs-vswitchd+0x42dee4)
Address 0x191844 is located in stack of thread T0 at offset 68 in frame
0 0x6d391f in xlate_group_bucket ofproto/ofproto-dpif-xlate.c:4751
This frame has 3 object(s):
[32, 1056) 'action_list_stub' (line 4760) <== Memory access at
offset 68 is inside
this variable
[1184, 1248) 'action_list' (line 4761)
[1280, 1344) 'action_set' (line 4762)
SUMMARY: AddressSanitizer: stack-use-after-return
ofproto/ofproto-dpif-trace.c:704:49 in ofproto_trace_recirc_node
Fix that by copying the action.
Fixes: d072d2de01 ("ofproto-dpif-trace: Improve NAT tracing.")
Reported-by: Ales Musil <amusil@redhat.com>
Reviewed-by: Adrian Moreno <amorenoz@redhat.com>
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Partially revert db5a101931, this was to avoid warning, however we
shouldn't use pointer to "uint32_t" when the data are potentially
unaligned [0]. Use pointer to "uint8_t" right from the start, this
requires us to use ALIGNED_CAST for the get_unaligned_u32, which is
fine in that case, because the function uses
" __attribute__((__packed__))" struct to access the underlying "uint32_t".
lib/hash.c:46:22: runtime error: load of misaligned address
0x507000000065 for type 'const uint32_t *' (aka 'const unsigned int *'),
which requires 4 byte alignment
0x507000000065: note: pointer points here
73 62 2e 73 6f 63 6b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
^
0 0x6191cb in hash_bytes ovs/lib/hash.c:46:9
1 0x69d064 in hash_string ovs/lib/hash.h:404:12
2 0x69d064 in hash_name ovs/lib/shash.c:29:12
3 0x69d064 in shash_find ovs/lib/shash.c:237:49
4 0x69dada in shash_find_data ovs/lib/shash.c:251:31
5 0x507987 in add_remote ovs/ovsdb/ovsdb-server.c:1382:15
6 0x507987 in parse_options ovs/ovsdb/ovsdb-server.c:2659:13
7 0x507987 in main ovs/ovsdb/ovsdb-server.c:751:5
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior lib/hash.c:46:22
[0] https://github.com/llvm/llvm-project/issues/90848
Fixes: db5a101931 ("clang: Fix the alignment warning.")
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Acked-by: Simon Horman <horms@ovn.org>
Signed-off-by: Ales Musil <amusil@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
GCC 14 renamed one of the AVX512 defines to have only single
underscore instead of two [0]. Add the single underscore define to
keep compatibility with multiple GCC versions.
[0] aea8e41055
Tested-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Simon Horman <horms@ovn.org>
Signed-off-by: Ales Musil <amusil@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Remove the notion of cluster/leave --force since it was never
implemented. Instead of these instructions, document how a broken
cluster can be re-initialized with the old database contents.
Acked-by: Simon Horman <horms@ovn.org>
Signed-off-by: Ihar Hrachyshka <ihrachys@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Currently conntrack uses a single large cmap for all connections stored.
This cmap contains all connections for all conntrack zones which are
completely separate from each other. By separating each zone to its own
cmap we can significantly optimize the performance when using multiple
zones.
The change fixes a similar issue as [1] where slow conntrack zone flush
operations significantly slow down OVN router failover. The difference is
just that this fix is used whith dpdk, while [1] was when using the ovs
kernel module.
As we now need to store more cmap's the memory usage of struct conntrack
increases by 524280 bytes. Additionally we need 65535 cmaps with 128
bytes each. This leads to a total memory increase of around 10MB.
Running "./ovstest test-conntrack benchmark 4 33554432 32 1" shows no
real difference in the multithreading behaviour against a single zone.
Running the new "./ovstest test-conntrack benchmark-zones" show
significant speedups as shown below. The values for "ct execute" are for
acting on the complete zone with all its entries in total (so in the
first case adding 10,000 new conntrack entries). All tests are run 1000
times.
When running with 1,000 zones with 10,000 entries each we see the
following results (all in microseconds):
"./ovstest test-conntrack benchmark-zones 10000 1000 1000"
+------+--------+---------+---------+
| Min | Max | 95%ile | Avg |
+------------------------+------+--------+---------+---------+
| ct execute (commit) | | | | |
| with commit | 2266 | 3505 | 2707.06 | 2592.06 |
| without commit | 2411 | 12730 | 4432.50 | 2736.78 |
+------------------------+------+--------+---------+---------+
| ct execute (no commit) | | | | |
| with commit | 699 | 1238 | 886.15 | 722.67 |
| without commit | 700 | 3377 | 1934.42 | 803.53 |
+------------------------+------+--------+---------+---------+
| flush full zone | | | | |
| with commit | 619 | 1122 | 901.36 | 679.15 |
| without commit | 618 | 105078 | 64591 | 2886.46 |
+------------------------+------+--------+---------+---------+
| flush empty zone | | | | |
| with commit | 0 | 5 | 1.00 | 0.64 |
| without commit | 54 | 87469 | 64520 | 2172.25 |
+------------------------+------+--------+---------+---------+
When running with 10,000 zones with 1,000 entries each we see the
following results (all in microseconds):
"./ovstest test-conntrack benchmark-zones 1000 10000 1000"
+------+--------+---------+---------+
| Min | Max | 95%ile | Avg |
+------------------------+------+--------+---------+---------+
| ct execute (commit) | | | | |
| with commit | 215 | 287 | 231.88 | 222.30 |
| without commit | 214 | 1692 | 569.18 | 285.83 |
+------------------------+------+--------+---------+---------+
| ct execute (no commit) | | | | |
| with commit | 68 | 97 | 74.69 | 70.09 |
| without commit | 68 | 300 | 158.40 | 82.06 |
+------------------------+------+--------+---------+---------+
| flush full zone | | | | |
| with commit | 47 | 211 | 56.34 | 50.34 |
| without commit | 48 | 96330 | 63392 | 63923 |
+------------------------+------+--------+---------+---------+
| flush empty zone | | | | |
| with commit | 0 | 1 | 1.00 | 0.44 |
| without commit | 3 | 109728 | 63923 | 3629.44 |
+------------------------+------+--------+---------+---------+
Comparing the averages we see:
* a moderate performance improvement for conntrack_execute with or
without commiting of around 6% to 23%
* a significant performance improvement for flushing a full zone of
around 75% to 99%
* an even more significant improvement for flushing empty zones since we
no longer need to check any unrelated connections
[1] 9ec849e8aa
Signed-off-by: Felix Huettner <felix.huettner@mail.schwarz>
Signed-off-by: Simon Horman <horms@ovn.org>
The current test-conntrack benchmark command runs with multiple threads
against a single conntrack zone. We now add a new benchmark-zones
command that allows us to check the performance between multiple zones.
We in there test the following scenarios for one zone while other zones
also contain entries:
1. Flushing a single full zone
2. Flushing a single empty zone
3. Committing new conntrack entries against a single zone
4. Running conntrack_execute without commit against the entries of a
single zone
Signed-off-by: Felix Huettner <felix.huettner@mail.schwarz>
Signed-off-by: Simon Horman <horms@ovn.org>
Update link to pacemaker main page as the existing link is broken.
Also, use HTTPS.
Broken link flagged by make check-docs
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Simon Horman <horms@ovn.org>
Sparse doesn't understand _Float16 and some other types used by
immintrin.h from GCC 13. This breaks sparse builds with DPDK on
Fedora 38+ and Ubuntu 24.04.
Add another sparse-specific header to workaround the problem. We do
need some of the functions and types defined in these headers, so we
can't really stab out the whole header. Carving out the main offenders
instead by defining the inclusion guards.
This is fragile and depends on internals of immintrin and underlying
headers, but I'm not sure what the better way to solve the issue
would be. This approach should be more or less portable between
compilers, because it only defines a few specific variables. We may
have to add more as GCC headers change over time.
This fixes the build with a following config on F38 and Ubuntu 24.04:
./configure --enable-sparse --with-dpdk=yes --enable-Werror
Acked-by: Ales Musil <amusil@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Clang 18.1.3-2.fc41 throws a warning:
lib/tc.c:3060:25: error: field 'sel' with variable sized type
'struct tc_pedit_sel' not at the end of a struct or class is a
GNU extension [-Werror,-Wgnu-variable-sized-type-not-at-end]
3060 | struct tc_pedit sel;
| ^
Refactor the structure into a proper union to avoid the build failure.
Interestingly, clang 18.1.3-2.fc41 on Fedora throws a warning, but
relatively the same version 18.1.3 (1) on Ubuntu 24.04 does not.
Acked-by: Ales Musil <amusil@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Cirrus CI is broken on FreeBSD 13.3 due to clang version update.
It now complains about snprintf truncation the same way GCC does:
tests/test-util.c:1129:16: error: 'snprintf' will always be truncated;
specified size is 5, but format string expands to at least 6
[-Werror,-Wformat-truncation]
1129 | ovs_assert(snprintf(s, 5, "abcde") == 5);
| ^
Clang 17 on FreeBSD 14.0 works fine, but new Clang 18.1.4 on 13.3
fails to build.
Fix that by disabling Clang diagnostic the same way as we do for GCC.
Unfortunately, the pragma's are compiler-specific, so cannot be
combined, AFAIK.
Acked-by: Ales Musil <amusil@redhat.com>
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
When no parameters other than the datapath are specified a segfault
occurs.
Fix it by checking the argument access is inside the bounds.
Signed-off-by: Paolo Valerio <pvalerio@redhat.com>
Acked-by: Kevin Traynor <ktraynor@redhat.com>
Signed-off-by: Simon Horman <horms@ovn.org>
When failing to get flow control parameters use VLOG_WARN_BUF()
to expose the error string in ovs-vsctl show.
Signed-off-by: Roi Dayan <roid@nvidia.com>
Suggested-by: Simon Horman <horms@ovn.org>
Acked-by: Eli Britstein <elibr@nvidia.com>
Signed-off-by: Simon Horman <horms@ovn.org>
If the new snapshot received with INSTALL_SNAPSHOT request contains
a different election timer value, the timer is updated, but the
probe intervals for RAFT connections are not.
Fix that by updating probe intervals whenever we get election timer
from the log.
Fixes: 14b2b0aad7 ("raft: Reintroduce jsonrpc inactivity probes.")
Acked-by: Mike Pattrick <mkp@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Inactivity probe interval on RAFT connections depend on a value of the
election timer. However, the actual value is not known until the
database snapshot with the RAFT information is received by a joining
server. New joining server is using a default 1 second until then.
In case a new joining server is trying to join an existing cluster
with a large database, it may take more than a second to generate and
send an initial database snapshot. This is causing an inability to
actually join this cluster. Joining server sends ADD_SERVER request,
waits 1 second, sends a probe, doesn't get a reply within another
second, because the leader is busy preparing and sending an initial
snapshot to it, disconnects, repeat.
This is not an issue for the servers that did already join, since
their probe intervals are larger than election timeout.
Cooperative multitasking also doesn't fully solve this issue, since
it depends on election timer, which is likely higher in the existing
cluster with a very big database.
Fix that by using the maximum election timer value for inactivity
probes until the actual value is known. We still shouldn't completely
disable the probes, because in the rare event the connection is
established but the other side silently goes away, we still want to
disconnect and try to re-establish the connection eventually.
Since probe intervals also depend on the joining state now, update
them when the server joins the cluster.
Fixes: 14b2b0aad7 ("raft: Reintroduce jsonrpc inactivity probes.")
Reported-by: Terry Wilson <twilson@redhat.com>
Reported-at: https://issues.redhat.com/browse/FDP-144
Acked-by: Mike Pattrick <mkp@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
If the database is particularly large (multi-GB), ovsdb-server can take
several minutes to come up. This tends to fall afoul of the default
systemd start timeout, which is typically 90s, putting the service into
an infinite restart loop.
To avoid this, set the timeout to a more generous 5 minutes.
This change brings ovsdb-server's timeout in line with ovs-vswitchd,
which got the same treatment in commit c1c69e8a45 ("rhel/systemd: Set
ovs-vswitchd timeout to 5 minutes").
Acked-by: Simon Horman <horms@ovn.org>
Signed-off-by: Chris Riches <chris.riches@nutanix.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
The Python persistent UUID tests should have the keyword "python"
added so that TESTSUITEFLAGS="-k python" will not miss testing
them.
Fixes: 55b9507e68 ("ovsdb-idl: Add the support to specify the uuid for row insert.")
Signed-off-by: Terry Wilson <twilson@redhat.com>
Tested-by: Simon Horman <horms@ovn.org>
Signed-off-by: Simon Horman <horms@ovn.org>
Before the patch, the size of the backlog depended on the type of socket
(UNIX vs INET) as well as on the language (C vs Python), specifically:
- python used backlog size = 10 for all sockets;
- C used 64 for UNIX sockets but 10 for INET sockets.
This consolidates the values across the board. It effectively bumps the
number of simultaneous connections to python unixctl servers to 64. Also
for INET C servers too.
The rationale to do it, on top of consistency, is as follows:
- fmt_pkt in ovn testsuite is limited by python server listen backlog,
and as was found out when adopting the tool, it is sometimes useful to
run lots of parallel calls to fmt_pkt unixctl server in some tests.
(See [1] for example.)
- there is a recent report [2] on discuss@ ML where the reporter noticed
significant listen queue overflows in some scenarios (large openstack
deployments; happens during leader transition when hundreds of neutron
nodes - with dozens of neutron api workers each - simultaneously
reconnect to the same northbound leader.) Note: While there is no
clear indication that this backlog size bump would resolve the
reported issues, it would probably help somewhat.
[1] 0baca3e519
[2] https://mail.openvswitch.org/pipermail/ovs-discuss/2024-April/053049.html
Signed-off-by: Ihar Hrachyshka <ihrachys@redhat.com>
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Simon Horman <horms@ovn.org>
VLOG_WARN_BUF() is allocating memory for the error string and should
e used if the configuration cannot continue and error is being returned
so the caller has indication of releasing the pointer.
Change to VLOG_WARN() to keep the logic that error is not being
returned.
Fixes: f4336f504b ("netdev-dpdk: Add option to configure VF MAC address.")
Signed-off-by: Roi Dayan <roid@nvidia.com>
Acked-by: Gaetan Rivet <gaetanr@nvidia.com>
Acked-by: Eli Britstein <elibr@nvidia.com>
Signed-off-by: Simon Horman <horms@ovn.org>
Current regexp is not good enough. OpenSSL 3.3.0 is now available
and unfortunately the regexp is matching both 3.3.0 and 3.0.13.
All the AppVeyor runs are currently failing because of this.
Making it more restrictive by matching on the start of the string,
explicit dots and numbers after the last dot. Hopefully, this is
good enough.
In addition, taking only the first result just in case it mismatches
again.
Fixes: 9d8208484a ("appveyor: Build with OpenSSL 3.0.")
Acked-by: Simon Horman <horms@ovn.org>
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
The current __check_doc_is_listed() verifies that the new .rst file is
listed in Documentation/automake.mk with the full path (i.e:
"{directory}/{filename}").
While this holds true for generic documentation files, which are added
to DOC_SOURCE with the full path, it's not true for rST manpages which
are added only by filename to RST_MANPAGES target (see
Documentation/automake.mk).
This makes the current implementation of the check to incorrectly raise
a warning as follows even though the patch does add the file to
RST_MANPAGES:
"""
WARNING: New doc ovs-flowviz.8.rst not listed in
Documentation/automake.mk
"""
Fix it by making the {dir}/ part of the docre regexp optional.
Signed-off-by: Adrian Moreno <amorenoz@redhat.com>
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Simon Horman <horms@ovn.org>
We pinned the python version to 3.9 because we had issues building
older meson 0.47.1 with python 3.10. Since then meson was updated to
0.53.2 in our CI, but we didn't reconsider the python version.
Newer versions of python uncover more issues with our python files.
And newer major distributions are using newer versions of python. But
we do not really want to use bleeding edge of python releases either to
avoid unexpected CI failures that need immediate fixes.
Pin python version to 3.12 as it is the latest released version and we
should not have any issues with this version.
While at it, updating meson to a newer version that plays nicely with
python 3.12. We do not really care much about the version we use here
as long as it is able to build the version of DPDK we're using. Meson
has no LTS releases, as far as I can tell, so just choosing the latest
stable 1.4.x series. It should be fine to use for a next few years.
Major distributions are using 1.0+ versions. Upcoming F40 and Ubuntu
24.03 have meson 1.3.
It would also be nice to test the minimal supported version of python,
but 3.6 is not available in setup-python for 22.04. The oldest is 3.7.
And 3.7 is EoL, so pip fails to install some of our dependencies. The
oldest version we can use today is 3.8. But, in the end, this becomes
a race against older python versions reaching end of their life and
packages dropping support of these versions. This may cause unexpected
CI failures. So, not doing that for now.
Acked-by: Simon Horman <horms@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Missing and extra spaces, missing empty lines, unused imports and
variables, long lines.
Decided to just comment out the unused 'tail' and 'head' as they
seem useful in documenting the meaning of the words.
Files added to flake8-check to avoid future issues.
Acked-by: Simon Horman <horms@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
ovsdb-doc script generates the following syntax warning while running
with Python 3.12:
/ovsdb/ovsdb-doc:240: SyntaxWarning: invalid escape sequence '\{'
s += """
This doesn't cause a build failure because so far it's only a warning,
but it will become a syntax error in the future.
Fix that by converting to a raw string and removing unnecessary
escape sequences.
Adding ovsdb-doc to flake8-check to avoid re-introducing issues in
the future. This means also fixing all the other issues with the
script like unused imports and variables, long lines, missing empty
lines, wildcarded imports. Also cleaning up one place that handles
compatibility with Python 2 types, since we do not support Python 2
for a long time now.
Acked-by: Simon Horman <horms@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
The OvS primary development branch has been renamed main
so there is no longer any need for this CI configuration
to refer to master.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Acked-by: Ilya Maximets <i.maximets@ovn.org>
Signed-off-by: Simon Horman <horms@ovn.org>
The OvS primary development branch has been renamed main
so there is no longer any need for this CI configuration
to refer to master.
Acked-by: Alin Gabriel Serdean <aserdean@ovn.org>
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Acked-by: Ilya Maximets <i.maximets@ovn.org>
Signed-off-by: Simon Horman <horms@ovn.org>
The previously enabled 'hacking' checks were only applicable to Python 2
code. OVS doesn't support Python 2 for a while now so it's fine to
remove the dependency on hacking.
A similar change landed in OVN a while ago:
https://github.com/ovn-org/ovn/commit/271186fa7d76
Acked-by: Simon Horman <horms@ovn.org>
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Current code checks spelling of names in commit message tags and that
makes no sense.
Most of the tags are explicitly handled, but tags like 'Tested-by' or
other lesser used ones are falling through to the spellchecker and
need to be excluded.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Currently, calls like ovs_assert() just print out a condition that
caused assertion to fail. But it may be not enough to understand what
exactly has happened, especially if assertion failed in some generic
function like dp_packet_resize() or similar.
Print the stack trace along with the abort message to give more context
for the later debugging.
This should be especially useful in case the issue happens in an
environment with core dumps disabled.
Adding the log to vlog_abort() to cover a little more cases where
VLOG_ABORT is called and not only assertion failures.
It would be nice to also have stack traces in case of reaching the
OVS_NOT_REACHED(). But this macro is used in some places as a last
resort and should not actually do more than just stopping the process
immediately. And it also can be used in contexts without logging
initialized. Such a change will need to be done more carefully.
Better solution might be to use VLOG_ABORT() where appropriate instead.
Acked-by: Kevin Traynor <ktraynor@redhat.com>
Acked-by: Simon Horman <horms@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Recently OVS adopted a policy of using the inclusive naming word list v1
[1, 2].
In keeping with this policy rename the primary development branch from
'master' to 'main'. This patch does not actually make that change, but
rather updates references to the branch in documentation in the source
tree. It is intended to be applied at (approximately) the same time
that the change is made.
OVS is currently hosted on GitHub. We can expect the following behaviour
after the rename:
1. GitHub pull requests against are renamed branch are automatically
re-homed on new branch
2. GitHub Issues do not seem to be affected - at least the test issue I
created had no association with a branch
3. URLs accessed via the GitHub web UI are automatically renamed
(so long as a new branch called master is not created).
4. Using the git cli command, fetch will fetch the new branch (main),
and fetch -p will remove (prune) the old branch (master)
[1] df5e5cf431 ("Documentation: Add section on inclusive language.")
[2] https://inclusivenaming.org/word-lists/
Signed-off-by: Simon Horman <horms@ovn.org>
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Acked-by: Aaron Conole <aconole@redhat.com>
Acked-by: Ilya Maximets <i.maximets@ovn.org>
---
Notes:
* Now is the time to raise any concerns regarding this patch.
It is planned to implement this change next week.
* If you have an automation that fetches the master branch then
the suggested action is:
1. Before the branch rename occurs: update the automation to pull main an
fall back to pulling master if that fails
2. After the rename occurs: Update the automation to only fetch main
* After the change it may be necessary to update your local
git configuration for checked out branches.
For example:
# Fetch origin: new remote main branch; remote master branch is deleted
git fetch -tp origin
# Rename local branch
git branch -m master main
# Update local main branch to use remote main branch as it's upstream
git branch --set-upstream-to=origin/main main
* As a follow-up, after the rename, I plan to post a patch which removes
references to master in CI jobs
Coverity reports a false positive below:
Ofproto_class_find__() may return NULL, and dereference it to cause segfault.
This patch is made just to avoid false-positive Coverity report.
Tested-by: Zhang YuHuang <zhangyuhuang@ruijie.com.cn>
Signed-off-by: Lin Huang <linhuang@ruijie.com.cn>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
The vlog - Python3 test makes use of output from Python
Tracebacks in its test assertion.
In Python 3.13 a line with tophat (``^``) markers is added below
Tracebacks from calls to assert [0], which makes the test fail.
This change of behavior is also backported to the Python 3.12 and
3.11 stable branches [1].
Strip lines containing one or more occurrence of the ``^``
character from the output before performing the test assertions.
0: https://github.com/python/cpython/pull/105935
1: https://github.com/python/cpython/issues/116034
Reported-at: https://launchpad.net/bugs/2060434
Signed-off-by: Frode Nordahl <fnordahl@ubuntu.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
This patch add another set of keywords based on the results
of the last thousand committed patches.
Acked-by: Simon Horman <horms@ovn.org>
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
ukey_install() returns boolean signaling if the ukey was installed
or not. Installation may fail for a few reasons:
1. Conflicting ukey.
2. Mutex contention while trying to replace existing ukey.
3. The same ukey already exists and active.
Only the first case here signals an actual problem. Third one is
a little odd for userspace datapath, but harmless. Second is the
most common one that can easily happen during normal operation
since other threads like revalidators may be currently working on
this ukey preventing an immediate access.
Since only the first case is actually worth logging and it already
has its own log message, removing the 'upcall installation fails'
warning from the upcall_cb(). This should fix most of the random
failures of userspace system tests in CI.
While at it, also fixing coverage counters. Mutex contention was
mistakenly counted as a duplicate upcall. ukey contention for
revalidators was counted only in one of two places.
New counter added for the ukey contention on replace. We should
not re-use existing upcall_ukey_contention counter for this, since
it may lead to double counting.
Fixes: 67f08985d7 ("upcall: Replace ukeys for deleted flows.")
Fixes: 9cec8274ed ("ofproto-dpif-upcall: Add VLOG_WARN_RL logs for upcall_cb() error.")
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Verify that the explicit drop action is re-probed if the hw-offload flag
is changed.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Eric Garver <eric@garver.life>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Exercise the drop action in the datapath. This specific tests triggers
an xlate_error.
For the kernel datapath skb drop reasons can then be seen while this
test runs.
# perf trace -e skb:kfree_skb --filter="reason >= 0x30000"
0.000 ping/1275884 skb:kfree_skb(skbaddr: 0xffff8acd76546000, \
location: 0xffffffffc0ee3634, protocol: 2048, reason: 196611)
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Eric Garver <eric@garver.life>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Kernel support has been added for this action. As such, we need to probe
the datapath for support.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Eric Garver <eric@garver.life>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
The next commit will convert a dp feature from bool to atomic_bool. As
such we have to add support to the macros and functions. We must pass by
reference instead of pass by value because all the atomic operations
require a reference.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Eric Garver <eric@garver.life>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
This is prep for adding a different OVS_ACTION_ATTR_ enum value. This
action, OVS_ACTION_ATTR_DEC_TTL, is not actually implemented. However,
to make -Werror happy we must add a case to all existing switches.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Eric Garver <eric@garver.life>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Previously the kernel did not provide a netlink interface to flush/list
only conntrack entries matching a specific zone. With [1] and [2] it is now
possible to flush and list conntrack entries filtered by zone. Older
kernels not yet supporting this feature will ignore the filter.
For the list request that means just returning all entries (which we can
then filter in userspace as before).
For the flush request that means deleting all conntrack entries.
The implementation is now identical to the windows one, so we combine
them.
These significantly improves the performance of flushing conntrack zones
when the conntrack table is large. Since flushing a conntrack zone is
normally triggered via an openflow command it blocks the main ovs thread
and thereby also blocks new flows from being applied. Using this new
feature we can reduce the flushing time for zones by around 93%.
In combination with OVN the creation of a Logical_Router (which causes
the flushing of a ct zone) could block other operations, e.g. the
failover of Logical_Routers (as they cause new flows to be created).
This is visible from a user perspective as a ovn-controller that is idle
(as it waits for vswitchd) and vswitchd reporting:
"blocked 1000 ms waiting for main to quiesce" (potentially with ever
increasing times).
The following performance tests where run in a qemu vm with 500.000
conntrack entries distributed evenly over 500 ct zones using `ovstest
test-netlink-conntrack flush zone=<zoneid>`.
| flush zone with 1000 entries | flush zone with no entry |
+---------------------+----------+---------------------+----------|
| with the patch | without | with the patch | without |
+----------+----------+----------+----------+----------+----------|
| v6.8-rc4 | v6.7.1 | v6.8-rc4 | v6.8-rc4 | v6.7.1 | v6.8-rc4 |
+---------+----------+----------+----------+----------+----------+----------|
| Min | 0.260 | 3.946 | 3.497 | 0.228 | 3.462 | 3.212 |
| Median | 0.319 | 4.237 | 4.349 | 0.298 | 4.460 | 4.010 |
| 90%ile | 0.335 | 4.367 | 4.522 | 0.325 | 4.662 | 4.572 |
| 99%ile | 0.348 | 4.495 | 4.773 | 0.340 | 4.931 | 6.003 |
| Max | 0.362 | 4.543 | 5.054 | 0.348 | 5.390 | 6.396 |
| Mean | 0.320 | 4.236 | 4.331 | 0.296 | 4.430 | 4.071 |
| Total | 80.02 | 1058 | 1082 | 73.93 | 1107 | 1017 |
[1]: eff3c558bb
[2]: fa173a1b4e
Acked-by: Mike Pattrick <mkp@redhat.com>
Acked-by: Aaron Conole <aconole@redhat.com>
Co-Authored-By: Luca Czesla <luca.czesla@mail.schwarz>
Signed-off-by: Luca Czesla <luca.czesla@mail.schwarz>
Co-Authored-By: Max Lamprecht <max.lamprecht@mail.schwarz>
Signed-off-by: Max Lamprecht <max.lamprecht@mail.schwarz>
Signed-off-by: Felix Huettner <felix.huettner@mail.schwarz>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
In the flush tuple code path, while populating the conn_key,
reverse_icmp_type() gets called for both icmp and icmpv6 cases,
while, depending on the proto, its respective helper should be
called, instead.
The above leads to an abort:
[...]
__GI_abort () at abort.c:79
reverse_icmp_type (type=128 '\200') at lib/conntrack.c:1795
tuple_to_conn_key (...) at lib/conntrack.c:2590
in conntrack_flush_tuple (...) at lib/conntrack.c:2787
in dpif_netdev_ct_flush (...) at lib/dpif-netdev.c:9618
ct_dpif_flush_tuple (...) at lib/ct-dpif.c:331
ct_dpif_flush (...) at lib/ct-dpif.c:361
dpctl_flush_conntrack (...) at lib/dpctl.c:1797
[...]
Fix it by calling reverse_icmp6_type() when needed.
Furthermore, self tests have been modified in order to exercise and
check this behavior.
Fixes: 271e48a0e2 ("conntrack: Support conntrack flush by ct 5-tuple")
Reported-at: https://issues.redhat.com/browse/FDP-447
Signed-off-by: Paolo Valerio <pvalerio@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Recent kernels introduced a mechanism that allows to evict colliding
entries in a closing state whereas they were previously considered as
parts of a non-recoverable clash.
This new behavior makes "conntrack - SNAT with port range with
exhaustion test" fail, as it relies on the previous assumptions.
Fix it by creating and not advancing the first entry in SYN_SENT to
avoid early eviction.
Suggested-by: Ilya Maximets <i.maximets@ovn.org>
Reported-at: https://issues.redhat.com/browse/FDP-486
Signed-off-by: Paolo Valerio <pvalerio@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
The Kernel datapath is no longer present in the primary development
branch of the OVS tree. Update documentation to more clearly reflect
this.
Documentation relating to the kernel datapath in the OVS tree can
be removed once 2.17 is EOL.
Also, update wording of affected text as there is more than one upstream
networking maintainer these days.
Signed-off-by: Simon Horman <horms@ovn.org>
Acked-by: Ilya Maximets <i.maximets@ovn.org>
