Currently the ovs-tcpdump utility creates a tap port to capture the
frames of a bond port.
If a user want to capture the packets from the bond port which member
interface's mtu is more than 1500. By default the utility creates a
tap port which mtu is 1500, regardless the member interface's mtu config.
So that user can't get the bond port frames which mtu is lager than 1500.
This patch fix this issue by checking the member interface's mtu and
set maximal mtu value to the tap port.
Acked-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Lin Huang <linhuang@ruijie.com.cn>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
When OVS fails to find an OpenFlow port for a packet received
from the upcall it just prints the warning like this:
|INFO|received packet on unassociated datapath port N
However, during the flow translation more information is available
as if the recirculation id wasn't found or it was a packet from
unknown tunnel port. Printing that information might be useful
to understand the origin of the problem.
Port translation functions already support extended error strings,
we just need to pass a variable where to store them.
With the change the output may be:
|INFO|received packet on unassociated datapath port N
(no OpenFlow port for datapath port N)
or
|INFO|received packet on unassociated datapath port N
(no OpenFlow tunnel port for this packet)
or
|INFO|received packet on unassociated datapath port N
(no recirculation data for recirc_id M)
Unfortunately, there is no good way to trigger this code from
current unit tests.
Acked-by: Mike Pattrick <mkp@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
When reference counting for json objects was introduced the
old json_clone() function became json_deep_clone(), but it
still calls shallow json_clone() while cloning objects and
arrays not really producing a deep copy.
Fixing that by making other functions to perform a deep copy
as well. There are no users for this functionality inside
OVS right now, but OVS exports this functionality externally.
'ovstest test-json' extended to test both versions of a clone
on provided inputs.
Fixes: 9854d473adea ("json: Use reference counting in JSON objects")
Acked-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
In OpenSSL 3.0 some functions were deprecated and replaced.
This commit adds some #ifdef to build without warning on both
OpenSSL 1.x and OpenSSL 3.x.
For OpenSSL 3.x, the default built-in DH parameters are used (as
suggested by SSL_CTX_set_dh_auto manpage).
Signed-off-by: Timothy Redaelli <tredaelli@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Since OpenSSL upstream commit 1696b8909bbe
("Remove -C from dhparam,dsaparam,ecparam") "openssl dhparam" doesn't
support -C anymore.
This commit changes generate-dhparams-c to generate dhparams.c by parsing
"openssl dhparam -in "$1" -text -noout" output directly.
The generated file won't be used on OpenSSL >= 3.0, but it's still
needed to be generated if OVS is built on OpenSSL < 3.0.
Signed-off-by: Timothy Redaelli <tredaelli@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
When segmentation fault occurred in ovn-northd, monitor will try to
restart the ovn-northd daemon process every 10s.
Assume the following scenarios: There is a segmentation fault and
the ovn-northd daemon process does not restart properly every time.
New fds are created each time the ovn-northd daemon process is
restarted by the monitor process, but old fds(fd[0]) owned by
the monitor process was not closed properly. One pipe leak for
each restart of the ovn-northd daemon process. After a long time
file descriptors were exhausted.
Fixes: e2ed6fbeb18c ("fatal-signal: Catch SIGSEGV and print backtrace.")
Signed-off-by: Fengqi Li <lifengqi@inspur.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
The "tcp vconn - refuse connection" test may fail due to a Connection
Refused error. The network stack returns ECONNREFUSED on a reset
connection in SYN_SENT state and EPIPE or ECONNRESET in all other
cases.
2022-09-19T17:45:48Z|00001|socket_util|INFO|0:127.0.0.1: listening on
port 34189
2022-09-19T17:45:48Z|00002|poll_loop|DBG|wakeup due to [POLLOUT][
POLLERR][POLLHUP] on fd 4 (127.0.0.1:47140<->) at ../lib/stream-fd.
c:153
test-vconn: unexpected vconn_connect() return value 111 (Connection
refused)
../../tests/vconn.at:21: exit code was 1, expected 0
530. vconn.at:21: 530. tcp vconn - refuse connection (vconn.at:21):
FAILED (vconn.at:21)
This was observed from a CI system, and isn't a common case.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Mike Pattrick <mkp@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Same as arpa/inet.h, the netinet/ip6.h on FreeBSD requires
netinet/in.h to be included first. So, adding a similar guard.
Also fixing one instance where this is not respected at the moment.
We do have FreeBSD CI these days, but it is still nice to have
a more clear error message.
Fixes: b2befd5bb2db ("sparse: Add guards to prevent FreeBSD-incompatible #include order.")
Acked-by: Mike Pattrick <mkp@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Update OVS CLI and relevant documentation to use DPDK 21.11.2.
DPDK 21.11.2 contains fixes for the CVEs listed below:
CVE-2022-28199 [1]
CVE-2022-2132 [2]
A bug was introduced in DPDK 21.11.1 by the commit
01e3dee29c02 ("vhost: fix unsafe vring addresses modifications").
This bug can cause a deadlock when vIOMMU is enabled and NUMA
reallocation of the virtqueues happen.
A fix [3] has been posted and pushed to the DPDK 21.11 branch.
If a user wishes to avoid the issue then it is recommended to use
DPDK 21.11.0 until the release of DPDK 21.11.3.
It should be noted that DPDK 21.11.0 does not benefit from the
numerous bug and CVE fixes addressed since its release.
If a user wishes to benefit from these fixes it is recommended to
use DPDK 21.11.2.
[1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-28199
[2] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2132
[3] https://patches.dpdk.org/project/dpdk/patch/20220725203206.427083-2-david.marchand@redhat.com/
Signed-off-by: Michael Phelan <michael.phelan@intel.com>
Acked-by: Kevin Traynor <ktraynor@redhat.com>
Signed-off-by: Ian Stokes <ian.stokes@intel.com>
Part of the uuidset implementation is taken from the OVN codebase where
it was added via commit 0e77b3bcbfe2 ("ovn-northd-ddlog: New
implementation of ovn-northd based on ddlog.").
We now extend that, adding a few helpers and tests.
Co-authored-by: Leonid Ryzhyk <lryzhyk@vmware.com>
Signed-off-by: Leonid Ryzhyk <lryzhyk@vmware.com>
Co-authored-by: Justin Pettit <jpettit@ovn.org>
Signed-off-by: Justin Pettit <jpettit@ovn.org>
Co-authored-by: Ben Pfaff <blp@ovn.org>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Reviewed-by: Ales Musil <amusil@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
'as' command of arm version may don't support option '--64', this
patch is to move the avx512 test into x86 branch to avoid this.
Fixes: 352b6c7116cd ("dpif-lookup: add avx512 gather implementation.")
Tested-by: Harry van Haaren <harry.van.haaren@intel.com>
Signed-off-by: Cheng Li <lic121@chinatelecom.cn>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Considering two DB rows, 'a' from table A and 'b' from table B (with
column 'ref_a' a reference to table A):
a = {A._uuid=<U1>}
b = {B._uuid=<U2>, B.ref_a=<U1>}
Assuming both records are inserted in the IDL client's in-memory view
of the database, if row 'b' is also deleted in the same run, it should
generate the following tracked changes:
- for table A:
- inserted records: a = {A._uuid=<U1>}
- for table B:
- inserted records: b = {B._uuid=<U2>, B.ref_a=<U1>}
- deleted records: b = {B._uuid=<U2>, B.ref_a=<U1>}
Before this patch, inserted and deleted records in table B
would (in some cases [0]) be b = {B._uuid=<U2>, B.ref_a=[]}.
Having B.ref_a=[] would violate the integrity of the database from
client perspective.
test-ovsdb has also been updated to show that one row can be
both inserted and deleted within one IDL run.
[0] In ovn-controller the fact that the reference is NULL caused a
crash in the following case, when both commands were handled by
ovn-controller within the same loop:
$ ovn-nbctl ls-add sw0 -- lsp-add sw0 sw0-port1 -- \
lsp-set-addresses sw0-port1 "50:54:00:00:00:01 192.168.0.2"
$ ovn-nbctl lsp-del sw0-port1
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2126450
Fixes: 91e1ff5dde39 ("ovsdb-idl: Don't reparse orphaned rows.")
Signed-off-by: Xavier Simonart <xsimonar@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Improve the test by adding and varying the MTU of a DPDK null port to check if
relevant mempools are created/(re)used.
Acked-by: Kevin Traynor <ktraynor@redhat.com>
Tested-by: Michael Phelan <michael.phelan@intel.com>
Signed-off-by: Sunil Pai G <sunil.pai.g@intel.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
When icmp error code send back to sender, currently ovs ct can't create
conntrack for the error code properly, this patch mainly fix the bug.
icmp error code test case:
1) packet too big.
2) network unreachable
3) parameter problem
Signed-off-by: ldejing <ldejing@vmware.com>
Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
This patch implemented meter action, currently, meter only support drop
method and only support one band. The overall implementation is, when a
packet comes in, it will first lookup meter according to the meter id,
then get the band->rates and delta time since last access the same meter
from the meter struct. Add the multiply result(band->rates * delta_time)
to bucket, finally bucket minus the packet size, if the result larger
than zero, allow the packet go through, otherwise deny the packet go
through.
Test case:
1. Setting the size meter size 3M, then the bandwidth was limit
around 3M;
ovs-ofctl -O OpenFlow13 add-meter br-test meter=2,kbps,\
band=type=drop,rate=3000
ovs-ofctl add-flow br-test "table=0,priority=1,ip \
actions=meter:2,normal" -O OpenFlow13
2. Setting the meter size 8M, then the bandwidth was limit
around 8M;
ovs-ofctl -O OpenFlow13 add-meter br-test meter=2,\
kbps,band=type=drop,rate=8000
ovs-ofctl add-flow br-test "table=0,priority=1,ip\
actions=meter:2,normal" -O OpenFlow13
Signed-off-by: ldejing <ldejing@vmware.com>
Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
Implementation on Windows:
IPv6 conntrack ip fragment feature use a link list to store ip
fragment. When ipv6 fragment module receives a fragment packet,
it will store length of the fragment, until to the received length
equal to the packet length before fragmented, it will reassemble
fragment packet to a complete packet and send the complete packet
to conntrack module. After conntrack processed the packet, fragment
module will divide the complete packet into small fragment and send
it to destination. Currently, ipv6 was implemented in a indenpent
module, for the reason it can reduce the risk of introduce bug to
ipv4 fragmenb module.
Testing Topology:
On the Windows VM runs on the ESXi host, two hyper-v ports attached
to the ovs bridge; one hyper-v port worked as client and the
other port worked as server.
Testing Case:
1.UdpV6
a) UdpV6 fragment with multiple ipv6 extension fields.
b) UdpV6 fragment in normal scenario.
c) UdpV6 fragment in nat scenario.
2.IcmpV6
a) IcmpV6 fragment in normal scenario.
b) IcmpV6 fragment in nat scenario.
Signed-off-by: ldejing <ldejing@vmware.com>
Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
This patch mainly support alg field in ct action when process
ftp/tftp traffic. Tftp with alg mainly parse the tftp packet
(IPv4/IPv6), extract connect info from the tftp packet and
create the related connection. For ftp, previous version has
supported process of ftp traffic. However, previous version
regard traffic from or to port 21 as ftp traffic, this is
incorrect in some scenario. This version adds alg field in ct for
ftp traffic, we could use ct(alg=ftp) to process any ftp traffic
from/to any port.
IPv4/IPv6.
Test cases:
1) ftp ipv4/ipv6 use alg field in the normal and nat scenario.
2) tftp ipv4/ipv6 use alg field in the normal and nat scenario.
Signed-off-by: ldejing <ldejing@vmware.com>
Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
In the recent upstream OVS Geneve IPV6 tunnel coding job, it is only supportting the case when the uplink offload
(UDP v6 offload parameter setting on the network adapter configuration) is disabled.
For Geneve IPV6 header setting, it needs set Transmit.IpHeaderChecksum in NDIS_TCP_IP_CHECKSUM_NET_BUFFER_LIST_INFO
to be 0. Elsewise we could observe the found issue on the report page.
After this patch, even the uplink UDP v6 offload is enabled(On WindowsServer 2019) by default the IPV6 Geneve tunnel
could send/receive packets without issues now. I have tested four kinds of network adapter drivers( E1000e ,vmxnet3 and
physical network adapter "Intel(R) Ethernet 10G X710 rNDC " and "Mellanox ConnectX-5 Adapter”. On the default offload
setting for the network adapter(Windows server2019) the IPV6 Geneve tunnel could be setup.
This patch needs to be applied to master and branch-3.0.
Test topo,
Setup one IPV6 Geneve Tunnel between 1 Windows VM and 1 Ubuntu server.
Windows VM(Windows server2019), vif0( 6000::2/40.1.1.10) vif1(5000:ed4d::2) ------
Ubuntu VM Eth2(5000:ed4d::9), name space ns1 with interface ns1_link(6000::9/40.1.1.2)
WinVM: ovs-vsctl.exe add-port br-int bms-tun0 -- set interface bms-tun0 type=geneve options:key=flow options:csum=true
options:local_ip="5000:ed4d::2" options:remote_ip="5000:ed4d::9" options:tos=inherit
Ubuntu VM:ovs-vsctl add-port br-int dst_tunnel -- set interface dst_tunnel type=geneve options:local_ip="5000:ed4d::1"
options:remote_ip="5000:ed4d::2"
Reported-at: https://github.com/openvswitch/ovs-issues/issues/260
Signed-off-by: Wilson Peng <pweisong@vmware.com>
Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
Fixes idl.Row's __str__ method to only print if the column exists on
the object. The Row object passed to the 'updates' argument of
Idl.notify only contains a subset of columns. Printing that argument
causes an AttributeError.
Fixes: 6a1c98461b46 ("Add a __str__ method to idl.Row")
Submitted-at: https://github.com/openvswitch/ovs/pull/392
Acked-by: Terry Wilson <twilson@redhat.com>
Signed-off-by: Christopher Aubut <christopher@aubut.me>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
If the PACKET_OUT from controller ends up with sending packet to
a bond interface, the main thread will take locks in the following
order:
handle_openflow
--> take ofproto_mutex
handle_packet_out
packet_xlate
output_normal
bond_update_post_recirc_rules
--> take rwlock in bond.c
If at the same time revalidator thread is processing other packet
with the output to the same bond:
xlate_actions
output_normal
bond_update_post_recirc_rules
--> take rwlock in bond.c
update_recirc_rules
ofproto_dpif_add_internal_flow
ofproto_flow_mod
--> take ofproto_mutex
So, it is possible for these 2 threads to lock each other by
taking one lock and waiting for another thread to release the
second lock.
It is also possible for the main thread to lock itself up by trying
to acquire ofproto_mutex for the second time, if it will actually
proceed with update_recirc_rules() after taking the bond rwlock.
The problem appears to be that bond_update_post_recirc_rules()
is called during the flow translation even if side effects are
prohibited, which is the case for openflow PACKET_OUT handling.
Skipping actual flow updates during the flow translation if
side effects are disabled to avoid the deadlock.
Since flows are not installed now when actions translated for
very first packet, installing initial flows in bond_reconfigure().
This will cover the case of allocating a new recirc_id.
Also checking if we need to update flows in bond_run() to cover
link state changes.
Regression test is added to catch the double lock case.
Reported-at: https://github.com/openvswitch/ovs-issues/issues/259
Reported-by: Daniel Ding <zhihui.ding@easystack.cn>
Fixes: adcf00ba35a0 ("ofproto/bond: Implement bond megaflow using recirculation")
Acked-by: Mike Pattrick <mkp@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
New commands 'revalidator/pause' and 'revalidator/resume'.
Not documented, since these should not be used in production
environments.
Will be used for unit tests in the next commit.
Acked-by: Mike Pattrick <mkp@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
GCC 12.2.1 on Fedora 36 generates the following false-positive
warning that is treated as error with -Werror:
tests/test-list.c: In function 'test_list_construction':
tests/test-list.c:110:9: error: 'values' may be used uninitialized
110 | check_list(&list, values, n);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
For some reason it fails to recognize that array will not
be used if 'n' equals zero.
Fix that by just initializing arrays in full before using,
since it's just a test code.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Most of commands in ovs-ofctl and ovs-appctl can display port names
instead of port numbers by using --names option. This change adds
similar functionality to ofproto/trace.
For backward compatibility, the default behavior is the same as
before.
Acked-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Nobuhiro MIKI <nmiki@yahoo-corp.jp>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
GNU grep 3.8 started complaining about use of obsolete egrep/fgrep:
egrep: warning: egrep is obsolescent; using grep -E
This breaks tests on such systems. All the instances was cleaned up
from the testsuite, but the checkpatch check is needed to catch issues
in new patches.
Acked-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
GNU grep 3.8 started to emit warnings when invoking egrep/fgrep. In some
cases this breaks tests that check stderr. Replace the commands with
their grep -E and grep -F counterparts throughout.
Reported-at: https://bugzilla.opensuse.org/show_bug.cgi?id=1203239
Submitted-at: https://github.com/openvswitch/ovs/pull/395
Signed-off-by: Andreas Stieger <Andreas.Stieger@gmx.de>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
When we apply meter police on both directions of TCP traffic, the
dumped stats is shown same (as shown below). This issue is introduced
by modifying the stats update strategy.
...,in_port(6),eth(),eth_type(0x0800),ipv4(frag=no), packets:1488557,
bytes:2089059644, used:0.040s, actions:meter(0),9
...,in_port(9),eth(),eth_type(0x0800),ipv4(frag=no), packets:1488557,
bytes:2089059644, used:0.040s, actions:meter(0),6
In previous patch, after parsing police action, the flower stats will
be updated by dumped meter table stats, which will result in the issue
above.
Thus, the stats of meter table should not be used when dumping flow
stats. Ignore the stats update when police.index belongs to meter.
Fixes: a9b8cdde69de ("tc: Add support parsing tc police action")
Signed-off-by: Tianyu Yuan <tianyu.yuan@corigine.com>
Reviewed-by: Baowen Zheng <baowen.zheng@corigine.com>
Signed-off-by: Simon Horman <simon.horman@corigine.com>
Acked-by: Eelco Chaudron <echaudro@redhat.com>
13.1 got released in May and now we have problems updating
some packages in 13.0 and CI is failing.
Update to 13.1 to unblock the CI.
Acked-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
For netdev_linux_update_via_netlink(), hint to the kernel that
we do not need it to gather netlink internal stats when we want
to update the netlink flags, as those stats are not rendered
within OVS.
Background:
ovs-vswitchd can spend quite a bit of time blocked by the kernel
during netlink calls, especially systems with many cores. This
time is dominated by the kernel-side internal stats gathering
mechanism in netlink, specifically:
inet6_fill_link_af
inet6_fill_ifla6_attrs
__snmp6_fill_stats64
In Linux 4.4+, there exists a hint for netlink requests to not
trigger the ipv6 stats gathering mechanism, which greatly reduces
the amount of time that ovs-vswitchd is on CPU.
Testing and Results:
Tested booting 320 VM's and measuring OVS utilization with perf
record, then visualized into a flamegraph using a patched version
of ovs 2.14.2. Calls under bridge_run() seem to get hit the worst
by this issue.
Before bridge_run() == 11.3% of samples
After bridge_run() == 3.4% of samples
Note that there are at least two observed netlink calls under
bridge_run that are still kernel stats heavy after this patch:
Call 1:
bridge_run -> netdev_run -> route_table_run -> route_table_reset ->
ovs_router_insert -> ovs_router_insert__ -> get_src_addr ->
netdev_ger_addr_list -> netdev_linux_get_addr_list -> getifaddrs
Since the actual netlink call is coming from getifaddrs() in glibc,
fixing would likely involve either duplicating glibc code in ovs
source or patch glibc.
Call 2:
bridge_run -> iface_refresh_stats -> netdev_get_stats ->
netdev_linux_get_stats -> get_stats_via_netlink
This does use netlink based stats; however, it isn't immediately
clear if just dropping the stats from inet6_fill_link_af would
impact anything or not. Given this call is more intermittent, its
of lesser concern.
Acked-by: Greg Smith <gasmith@nutanix.com>
Signed-off-by: Jon Kohler <jon@nutanix.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Using [NETNS|OVS]_DAEMONIZE will start tcpdump in the background,
and it will also make sure it gets killed in corner cases.
For the check_pkt_len tests, we also kill tcpdump between individual
tests in the same test case to avoid confusion when analyzing results.
This also required some changes to the awk expressions, as an extra
newline is added to the output when tcpdump gets stopped.
Fixes: 02dabb21f243 ("tests: Add check_pkt_len action test to system-offload-traffic.")
Suggested-by: David Marchand <david.marchand@redhat.com>
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
If tnl_port_should_receive() is false, we're looking for a normal
port, not a tunnel one. And it's better to print recirculation IDs
in hex since they are typically printed this way in flow dumps.
Fixes: d40533fc820c ("odp-util: Improve log messages and error reporting for Netlink parsing.")
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
When OFPROTO non-reversible actions are translated to data plane
actions, the only thing looked at is if there are more actions
pending. If this is the case, the action is encapsulated in a
clone().
This could lead to unnecessary clones if no meaningful data
plane actions are added. For example, the register pop in the
included test case.
The best solution would probably be to build the full action
path and determine if the clone is needed. However, this would
be a huge change in the existing design, so for now, we just try
to optimize the generated datapath flow. We can revisit this
later, as some of the pending CT issues might need this rework.
Fixes: feee58b9587f ("ofproto-dpif-xlate: Keep track of the last action")
Fixes: dadd8357f224 ("ofproto-dpif: Fix issue with non-reversible actions on a patch ports.")
Acked-by: Ales Musil <amusil@redhat.com>
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
A packet go through the encap openflow(set_field tun_id/src/dst)
The tunnel wc bits will be set. But it should be clear if the
original packet is non-tunnel. It is not necessary for datapath
wc the tunnel info for match(like the similar logic for vlan).
Signed-off-by: wenxu <wenxu@chinatelecom.cn>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
This makes the clone a little bit faster by avoiding multiple
incremental expansions with re-allocations on big sets.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
While creating a new database file and storing a new snapshot
into it, raft module by mistake updates the base offset for the
old file. So, the base offset of a new file remains zero. Then
the old file is getting replaced with the new one, copying new
offsets as well. In the end, after a full compaction, base offset
is always zero. And any offset is twice as large as zero. That
triggers a new compaction again at the earliest scheduled time.
In practice this issue triggers compaction every 10-20 minutes
regardless of the database load, after the first one is triggered
by the actual file growth or by the 24h maximum limit.
Fixes: 1b1d2e6daa56 ("ovsdb: Introduce experimental support for clustered databases.")
Reported-at: https://mail.openvswitch.org/pipermail/ovs-discuss/2022-August/051977.html
Reported-by: Oleksandr Mykhalskyi <oleksandr.mykhalskyi@netcracker.com>
Acked-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Cited commit correctly fixed the issue of incorrect reporting
of zero-length geneve option matches as wildcarded. But as a
side effect, exact match on the metadata length was added to
every tunnel flow match, even if the tunnel is not geneve.
That doesn't generate any functional issues, but it maybe
confusing to see 'tunnel(...,geneve(),...)' while looking at
datapath flow dumps for, e.g., vxlan tunnel flows.
Fix that by checking the port type before parsing geneve options.
tunnel() attribute itself doesn't have enough information to
figure out the tunnel type.
Fixes: 7a6c8074c5d2 ("netdev-offload-tc: Fix the mask for tunnel metadata length.")
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Reviewed-by: Roi Dayan <roid@nvidia.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Transaction history is used to construct database updates for clients.
But if the row didn't change it will never be used for monitor updates,
because ovsdb_monitor_changes_classify() will always return
OVSDB_CHANGES_NO_EFFECT. So, ovsdb_monitor_history_change_cb()
will never add it to the update.
This condition is very common for rows with references. While
processing strong references in ovsdb_txn_adjust_atom_refs() the
whole destination row will be cloned into transaction just to update
the reference counter. If this row will not be changed later in
the transaction, it will just stay in that state and will be added
to the transaction history. Since the data didn't change, both 'old'
and 'new' datums will be the same and equal to one in the database.
So, we're keeping 2 copies of the same row in memory and we are
never using them. In this case, we should just not add them to the
transaction history in the first place.
This change should save some space in the transaction history in case
of transactions with rows with big number of strong references.
This should also speed up the processing since we will not clone
these rows for transaction history and will not count their atoms.
Testing shows about 5-10% performance improvement in ovn-heater
test scenarios.
'n_atoms' counter for transaction adjusted to count only changed
rows, so we will have accurate value for a number of atoms in the
history.
Acked-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Some of the CTA_PROTOINFO_TCP nested attributes are not always
included in the received message, but the parsing logic considers them
as required, failing in case they are not found.
This was observed while monitoring some connections by reading the
events sent by conntrack:
./ovstest test-netlink-conntrack monitor
[...]
2022-08-04T09:39:02Z|00007|netlink_conntrack|ERR|Could not parse nested TCP protoinfo
options. Possibly incompatible Linux kernel version.
2022-08-04T09:39:02Z|00008|netlink_notifier|WARN|unexpected netlink message contents
[...]
All the TCP DELETE/DESTROY events fail to parse with the message
above.
Fix it by turning the relevant attributes to optional.
Signed-off-by: Paolo Valerio <pvalerio@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Python documentation suggests to do so "to avoid listing all the
PyTypeObject fields that you don't care about and also to avoid
caring about the fields' declaration order". And that does make
sense.
Acked-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
netdev_tc_flow_put() "consumes" the tunnel.tp_src value, but
it's never passed down to TC, and not parsed back. Fix that.
Reviewed-by: Roi Dayan <roid@nvidia.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Current offloading code supports only limited number of tunnel keys
and silently ignores everything it doesn't understand. This is
causing, for example, offloaded ERSPAN tunnels to not work, because
flow is offloaded, but ERSPAN options are not provided to TC.
There is a number of tunnel keys, which are supported by the userspace,
but silently ignored during offloading:
OVS_TUNNEL_KEY_ATTR_DONT_FRAGMENT
OVS_TUNNEL_KEY_ATTR_OAM
OVS_TUNNEL_KEY_ATTR_VXLAN_OPTS
OVS_TUNNEL_KEY_ATTR_ERSPAN_OPTS
OVS_TUNNEL_KEY_ATTR_CSUM is kind of supported, but only for actions
and for some reason is set from the tunnel port instead of the
provided action, and not currently supported for the tunnel key in
the match.
Addig a default case to fail offloading of unknown attributes. For
now explicitly allowing incorrect behavior for the DONT_FRAGMENT flag,
otherwise we'll break all tunnel offloading by default. VXLAN and
ERSPAN options has to fail offloading, because the tunnel will not
work otherwise. OAM is not a default configurations, so failing it
as well. The missing DONT_FRAGMENT flag though should, probably,
cause frequent flow revalidation, but that is not new with this patch.
Same for the 'match' key, only clearing masks that was actually
consumed, except for the DONT_FRAGMENT and CSUM flags, which are
explicitly allowed and highlighted as broken.
Also, destination port as well as CSUM configuration for unknown
reason was not taken from the actions list and were passed via HW
offload info instead of being consumed from the set() action.
Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2022-July/395522.html
Reported-by: Eelco Chaudron <echaudro@redhat.com>
Fixes: 8f283af89298 ("netdev-tc-offloads: Implement netdev flow put using tc interface")
Reviewed-by: Roi Dayan <roid@nvidia.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
If the key is zero, it doesn't mean we don't need to match on it.
Masks should be checked instead.
Fixes: 49a7961fca65 ("lib/tc: Avoid matching on tunnel ttl or tos if not needed")
Reviewed-by: Roi Dayan <roid@nvidia.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
netdev_tc_flow_put() ignores the tunnel.tp_dst mask. That results
in the exact match on the value. TC supports the masked match on
this field and it does return the mask back during the flow dump
even if it wasn't provided initially. OVS should correctly handle
that. There is a problem though. Some drivers (mlx5) doesn't
support offloading if the destination port is not an exact match [1].
Keeping the logic as-is for now, but making it explicit and somewhat
documented in the comment, so it is clear what is happening and we can
revisit this in the future.
[1] https://patchwork.ozlabs.org/project/openvswitch/patch/20220704224505.1117988-3-i.maximets@ovn.org/#2927396
Reviewed-by: Roi Dayan <roid@nvidia.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
'wc.masks.tunnel.metadata.present.len' must be a mask for the same
field in the flow key, but in the tc_flower structure it's the real
length of metadata masks.
That is correctly handled for the individual opt->length, setting all
the masks to 0x1f like it's done in the tun_metadata_to_geneve_mask__(),
but not handled for the main 'len' field.
Fix that by setting the mask to 0xff like it's done during the flow
translation in xlate_actions() and during the flow dump in the
tun_metadata_from_geneve_nlattr().
Also, flower always has an exact match on the present.len field
regardless of its value and regardless of this field being masked
by OVS flow translation layer while installing the flow. Hence,
all tunnel flows dumped from TC should have an exact match on
present.len and also UDPIF flag, because present.len doesn't make
sense without that flag. Without the change, zero-length options
match is incorrectly reported as a wildcard match. The side effect
though is that zero-length match on geneve options is reported even
for other tunnel types, e.g. vxlan. But that should be fairly
harmless. To avoid reporting a match on empty geneve options for
vxlan/etc. tunnels we'll need to check the tunnel port type, there
is no enough information in the TUNNEL attribute itself.
Extra checks and comments added around the code to better explain
what is going on.
Fixes: a468645c6d33 ("lib/tc: add geneve with option match offload")
Reviewed-by: Roi Dayan <roid@nvidia.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
