Remove one unused stub: netdev_dpdk_register() can't be called if DPDK
is disabled at build time.
Remove unneeded #ifdef in call to free_dpdk_buf.
Drop unneeded cast when calling free_dpdk_buf.
Acked-by: Sunil Pai G <sunil.pai.g@intel.com>
Signed-off-by: David Marchand <david.marchand@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Some macros for rculist have no users and there are no unit tests
specific to that library as well, so broken code wasn't spotted
while updating to multi-variable iterators.
Fixing multiple problems like missing commas, parenthesis, incorrect
variable and macro names.
Fixes: d293965d7b06 ("rculist: use multi-variable helpers for loop macros.")
Reported-by: Subrata Nath <subrata.nath@nokia.com>
Co-authored-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Alin-Gabriel Serdean <aserdean@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
The count of received multicast packets has been computed internally,
but not exposed to ovsdb. Fix this.
Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Mike Pattrick <mkp@redhat.com>
Acked-by: Michael Santana <msantana@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
The value is right-justified after the string parsing with
parse_int_string(), i.e. it is in BE byte order and aligned
to the right side of the array.
For example, the 0x10011 value in a 4-byte field will look
like 0x00 0x01 0x00 0x11.
However, value copy to the resulted ofpact is performed
from the start of the memory. So, in case the destination
size is smaller than the original field size, incorrect
part of the value will be copied.
In the 0x00 0x01 0x00 0x11 example above, if the copy is
performed to a 3-byte field, the first 3 bytes will be
copied, which are 0x00 0x01 0x00 instead of 0x01 0x00 0x11.
This leads to a problem where NXM_NX_REG3[0..16]=0x10011
turns into NXM_NX_REG3[0..16]=0x100 after the parsing.
Fix that by offsetting the starting position to the size
difference in bytes similarly to how it is done in
learn_parse_load_immediate().
While at it, changing &imm to imm.b in function calls that
expect byte arrays as an argument. The old way is technically
correct, but more error prone.
The mf_write_subfield_value() call was also incorrect.
However, the 'match' variable is actually not used for
anything since checking removal in commit:
dd43a558597b ("Do not perform validation in learn_parse();")
So, just removing the call and the 'match' variable
entirely instead of fixing it.
Fixes: 21b2fa617126 ("ofp-parse: Allow match field names in actions and brackets in matches.")
Reported-at: https://mail.openvswitch.org/pipermail/ovs-discuss/2022-November/052100.html
Reported-by: Thomas Lee <newsforthomas@engineer.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
If ovs node running on Windows is processing NAT action on the RX side, it will
reset pseudo header checksum only if the L4 checksum is same as the calculated
pseudo header checksum before NAT action.
Without the fix, if the L4 header checksum is filled with a pseudo header checksum
(sourceip, dstip, protocol, tcppayloadlen+tcpheaderlen) OVS will still do the
checksum update(replace some IP and port and recalculate the checksum). It will
lead to incorrect L4 header checksum.
Reported-at:https://github.com/openvswitch/ovs-issues/issues/265
Signed-off-by: Wilson Peng <pweisong@vmware.com>
Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
Populate the 'is_ipv6' field of 'struct rte_flow_tunnel', which can
be used in the implementation of tunnel pop action for DPDK PMD.
Fixes: be56e063d028 ("netdev-offload-dpdk: Support tunnel pop action.")
Signed-off-by: Chaoyong He <chaoyong.he@corigine.com>
Reviewed-by: Louis Peens <louis.peens@corigine.com>
Acked-by: Eli Britstein <elibr@nvidia.com>
Signed-off-by: Simon Horman <simon.horman@corigine.com>
Currently ethertype to prio hmap is static and the first ethertype
being used gets a lower priority. Usually there is an arp request
before the ip traffic and the arp ethertype gets a lower tc priority
while the ip traffic proto gets a higher priority.
In this case ip traffic will go through more hops in tc and HW.
Instead, reserve lower priorities for ip ethertypes.
Signed-off-by: Paul Blakey <paulb@nvidia.com>
Reviewed-by: Roi Dayan <roid@nvidia.com>
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Simon Horman <simon.horman@corigine.com>
The assignment of the features pointer is not doing
anything and can be removed.
CC: Justin Pettit <jpettit@ovn.org>
Signed-off-by: Roi Dayan <roid@nvidia.com>
Acked-by: Justin Pettit <jpettit@ovn.org>
Signed-off-by: Simon Horman <simon.horman@corigine.com>
CID 550702 (#1 of 1): Dereference null return value (NULL_RETURNS)
7. dereference: Dereferencing a pointer that might be NULL ex_type when calling nl_attr_get_u16.
Signed-off-by: Roi Dayan <roid@nvidia.com>
Signed-off-by: Simon Horman <simon.horman@corigine.com>
Fix coverity big parameter passed by value
CID 549858 (#1 of 1): Big parameter passed by value (PASS_BY_VALUE)
pass_by_value: Passing parameter metadata of type struct tun_metadata (size 272 bytes) by value,
which exceeds the medium threshold of 256 bytes
Signed-off-by: Roi Dayan <roid@nvidia.com>
Signed-off-by: Simon Horman <simon.horman@corigine.com>
The current version of meson used for building DPDK is 0.49.2.
This has the restriction of holding the required python version to 3.9.
A recent change [1] in DPDK bumped requirements on meson to 0.53.2.
Update the version of meson used to build DPDK to 0.53.2 to remove the
restriction.
[1] https://git.dpdk.org/dpdk/commit/?id=909ad7b80e5e
Signed-off-by: Ian Stokes <ian.stokes@intel.com>
Reviewed-by: David Marchand <david.marchand@redhat.com>
When a row is deleted, if the row has weak references to other rows, the
weak reference nodes attached to the destination rows (through
weak->dst_node hmap) are not destroyed.
Deleting weak references is properly handled when a row is modified. The
removed references are taken care by:
1. assess_weak_refs() figures out the deleted references from the row
and add them to txn_row->deleted_refs.
2. before commit, in ovsdb_txn_update_weak_refs() it finds the
destination row for each item in txn_row->deleted_refs (from step 1),
and destroy the corresponding weak references of the destination row.
However, when the row is deleted, the step 1 in assess_weak_refs() is
missing. It directly returns without adding the deleted references to
txn_row->deleted_refs. So, the destination nodes will keep those weak
references although the source side of the references are already
deleted. When such rows that originating weak references are created
and deleted, more and more such useless weak reference structures
accumulate in the memory, and can stay there until the destination rows
are deleted. It is possible that the destination row is never deleted,
and in such case the ovsdb-server memory keeps growing (although it is
not strictly memory leak, because the structures are still referenced).
This problem has an impact to applications like OVN SB DB - the memory
grows very fast in long-running deployments and finally causes OOM.
This patch fixes it by generating deleted_refs for deleted rows in
assess_weak_refs().
Fixes: 4dbff9f0a685 ("ovsdb: transaction: Incremental reassessment of weak refs.")
Signed-off-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
The loops for adding weak refs are quite similar. Abstract to a
function, which will be used by one more cases later. The patch also
changes the txn_row arg to the source row.
Signed-off-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
tc_del_qdisc() function only removes qdiscs with handle '1:0'. If for
some reason the interface has a qdisc with non-zero handle attached,
tc_del_qdisc() will not delete it and subsequent tc_install() will fail
to install a new qdisc.
The problem is that Libvirt by default is setting noqueue qdisc for all
tap interfaces it creates. This is done for performance reasons to
ensure lockless xmit.
The issue is causing non-working QoS in OpenStack setups since new
versions of Libvirt started to use OVS to configure it. In the past,
Libvirt configured TC on its own, bypassing OVS.
Removing the handle value from the deletion request, so any qdisc can
be removed. Changing the error checking to also pass ENOENT, since
that is the error reported if only default qdisc is present.
Alternative solution might be to use NLM_F_REPLACE, but that will be
a larger change with a potential need of refactoring.
Potential side effect of the change is that OVS may start removing
qdiscs that it didn't remove before. Though it's not a new issue and
'linux-noop' QoS type should be used for ports that OVS should not
touch. Otherwise, OVS owns qdiscs on all interfaces attached to it.
While at it, adding more logs as errors are not logged in any way
at the moment making the issue hard to debug.
Reported-at: https://bugzilla.redhat.com/2138339
Reported-at: https://mail.openvswitch.org/pipermail/ovs-discuss/2022-October/052088.html
Reported-at: https://github.com/openvswitch/ovs-issues/issues/268
Suggested-by: Slawek Kaplonski <skaplons@redhat.com>
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Similarly to what happens when CTA_TUPLE_MASTER is present in a ct
netlink dump, add the ability to print out the parent key to the
userspace implementation as well.
Signed-off-by: Paolo Valerio <pvalerio@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Offsets within 'rewrite' action are not 4-byte aligned, so has to
be accessed carefully.
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior lib/tc.c:1132:17 in
lib/tc.c:1132:17: runtime error: store to misaligned address 0x7fba215b2025
for type 'ovs_be32' (aka 'unsigned int'), which requires 4 byte alignment
0 0xd78857 in nl_parse_act_pedit lib/tc.c:1132:24
1 0xd68103 in nl_parse_single_action lib/tc.c:1936:15
2 0xd624ee in nl_parse_flower_actions lib/tc.c:2024:19
3 0xd624ee in nl_parse_flower_options lib/tc.c:2139:12
4 0xd5f082 in parse_netlink_to_tc_flower lib/tc.c:2187:12
5 0xd6a2a1 in tc_replace_flower lib/tc.c:3776:19
6 0xd2ae8f in netdev_tc_flow_put lib/netdev-offload-tc.c:2350:11
7 0x951d07 in netdev_flow_put lib/netdev-offload.c:318:14
8 0xcbb81a in parse_flow_put lib/dpif-netlink.c:2297:11
9 0xcbb81a in try_send_to_netdev lib/dpif-netlink.c:2384:15
10 0xcbb81a in dpif_netlink_operate lib/dpif-netlink.c:2455:23
11 0x8678ae in dpif_operate lib/dpif.c:1372:13
12 0x6bcc89 in handle_upcalls ofproto/ofproto-dpif-upcall.c:1674:5
13 0x6bcc89 in recv_upcalls ofproto/ofproto-dpif-upcall.c:905:9
14 0x6b7f9a in udpif_upcall_handler ofproto/ofproto-dpif-upcall.c:801:13
15 0xb54c5a in ovsthread_wrapper lib/ovs-thread.c:422:12
16 0x7fba2f2081ce in start_thread (/lib64/libpthread.so.0+0x81ce)
17 0x7fba2de39dd2 in clone (/lib64/libc.so.6+0x39dd2)
Fixes: 8ada482bbe19 ("tc: Add header rewrite using tc pedit action")
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
If OVS_CT_ATTR_TIMEOUT is included, the resulting output is
the following:
actions:ct(commit,timeout=1nat(src=10.1.1.240))
Fix it by trivially adding a trailing ',' to timeout as well.
Signed-off-by: Paolo Valerio <pvalerio@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
For some reason it is documented as 'rstp-port-path-cost', while
the code and some other bits of documentation use 'rstp-path-cost'.
Fixes: 9efd308e957c ("Rapid Spanning Tree Protocol (IEEE 802.1D).")
Reviewed-by: David Marchand <david.marchand@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
After user add a static fdb entry, the get_lru() function will always
return the static fdb entry. That's normal fdb entries will not age
out through mac_learning_run().
Fix the issue by modify the get_lru() function to check the
entry->expires field and not return the entry which entry->expires is
MAC_ENTRY_AGE_STATIC_ENTRY.
Adding a unit test for this.
Fixes: ccc24fc88d59 ("ofproto-dpif: APIs and CLI option to add/delete static fdb entry.")
Acked-by: Eelco Chaudron <echaudro@redhat.com>
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>
OVS now just allow the ARP Reply which the destination address is matched
against the known xbridge addresses to update tunnel neighbor. So when OVS
receive the gratuitous ARP from underlay gateway which the source address
and destination address are all gateway IP, tunnel neighbor will not be updated.
Fixes: ba07cf222a0c ("Handle gratuitous ARP requests and replies in tnl_arp_snoop()")
Fixes: 83c2757bd16e ("xlate: Move tnl_neigh_snoop() to terminate_native_tunnel()")
Acked-by: Paolo Valerio <pvalerio@redhat.com>
Signed-off-by: Han Ding <handing@chinatelecom.cn>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
The log should be printed with the member name, not the active member
name, and the active member does not judge whether it is NULL. If null,
OVS will crash with the following backtrace:
(gdb) bt
0 bond_check_admissibility (ofproto/bond.c:877)
1 is_admissible (ofproto/ofproto-dpif-xlate.c:2574)
2 xlate_normal (ofproto/ofproto-dpif-xlate.c:3027)
3 xlate_output_action (ofproto/ofproto-dpif-xlate.c:5284)
4 do_xlate_actions (ofproto/ofproto-dpif-xlate.c:6960)
5 xlate_actions (ofproto/ofproto-dpif-xlate.c:7924)
6 upcall_xlate (ofproto/ofproto-dpif-upcall.c:1237)
7 process_upcall (ofproto/ofproto-dpif-upcall.c:1456)
8 upcall_cb (ofproto/ofproto-dpif-upcall.c:1358)
9 dp_netdev_upcall (lib/dpif-netdev.c:7793)
10 handle_packet_upcall (lib/dpif-netdev.c:8255)
11 fast_path_processing (lib/dpif-netdev.c:8374)
12 dp_netdev_input__ (lib/dpif-netdev.c:8463)
13 dp_netdev_input (lib/dpif-netdev.c:8501)
14 dp_netdev_process_rxq_port (lib/dpif-netdev.c:5337)
15 pmd_thread_main (lib/dpif-netdev.c:6944)
16 ovsthread_wrapper (lib/ovs-thread.c:422)
17 ?? (/lib64/libpthread.so.0)
18 clone (/lib64/libc.so.6)
Fixes: 423416f58749 ("lacp: report desync in ovs threads enabling slave")
Signed-off-by: yangchang <yangchang@chinatelecom.cn>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
If ovs-tcpdump received HUP or TERM signal, mirror and mirror
interface should be destroyed. This often happens, when
controlling terminal is closed, like ssh session closed, and
other users use kill to terminate it.
Acked-by: Mike Pattrick <mkp@redhat.com>
Signed-off-by: Daniel Ding <zhihui.ding@easystack.cn>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Packets that could not be transmitted because the TXQ are full should be
taken into account in the global ovs_tx_failure_drops as it was the case
before commit 29b94e12d57d ("netdev-dpdk: Refactor the DPDK transmit
path.").
netdev_dpdk_eth_tx_burst() returns the number of packets that were *not*
transmitted. Add that number to stats.tx_failure_drops and only include
the packets that were dropped in previous steps afterwards.
Fixes: 29b94e12d57d ("netdev-dpdk: Refactor the DPDK transmit path.")
Acked-by: Mike Pattrick <mkp@redhat.com>
Signed-off-by: Robin Jarry <rjarry@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Since DPDK 21.05, the representor identifier now handles a relative VF
offset. The legacy representor ID seems only valid in certain cases
(first dpdk port).
Link: https://github.com/DPDK/dpdk/commit/cebf7f17159a8
Signed-off-by: Robin Jarry <rjarry@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Add tc action flags when adding police action to offload meter table.
There is a restriction that the flag of skip_sw/skip_hw should be same for
filter rule and the independent created tc actions the rule uses. In this
case, if we configure the tc-policy as skip_hw, filter rule will be created
with skip_hw flag and the police action according to meter table will have
no action flag, then flower rule will fail to add to tc kernel system.
To fix this issue, we will add tc action flag when adding police action to
offload a meter table, so it will allow meter table to work in tc software
datapath.
Fixes: 5c039ddc64ff ("netdev-linux: Add functions to manipulate tc police action")
Signed-off-by: Baowen Zheng <baowen.zheng@corigine.com>
Acked-by: Ilya Maximets <i.maximets@ovn.org>
Signed-off-by: Simon Horman <simon.horman@corigine.com>
This reverts commit dd9881ed55e6 ('tc: Fix stats dump when
using same meter table')
This patch doesn't solve the tc flow stats update issue and
will lead to failure of system-offloads-traffic testsuite, it
only counts packets surviving after the tc filter, rather than
hitting the filter
A following patch will come up to solve this flow stats update
issue
Signed-off-by: Tianyu Yuan <tianyu.yuan@corigine.com>
Acked-by: Ilya Maximets <i.maximets@ovn.org>
Signed-off-by: Simon Horman <simon.horman@corigine.com>
OVN is setting ct drop rule with a ct clear action.
OVS datapath behavior is if there is no forward action
the default is drop.
TC behavior is to continue with next match.
Fix to match tc to ovs behavior by setting last action
attribute as drop instead of pipe.
Also update lastused when parsing ct action.
example rule
recirc_id(0x1),in_port(2),ct_state(+trk),eth(),eth_type(0x0800),ipv4(frag=no),
packets:82, bytes:8036, used:2.108s, actions:ct_clear
Reviewed-by: Maor Dickman <maord@nvidia.com>
Signed-off-by: Roi Dayan <roid@nvidia.com>
Signed-off-by: Simon Horman <simon.horman@corigine.com>
The stats(byte_count) is got via function call
ofputil_decode_flow_stats_reply() and for OpenFlow15 it will also call
oxs_pull_entry__(). Currently we found on Windows the byte_count
counter is incorrect. It will get the byte_count on OpenFlow15
handling via ntohll(get_unaligned_be64(payload))
Quote the comments below from Ilya Maximets (thanks for the given
soluton and explanation):
static inline uint64_t get_unaligned_u64__(const uint64_t *p_)
...
return ntohll(((uint64_t) p[0] << 56)
| ((uint64_t) p[1] << 48)
| ((uint64_t) p[2] << 40)
| ((uint64_t) p[3] << 32)
| (p[4] << 24)
| (p[5] << 16)
| (p[6] << 8)
| p[7]);
And indeed the expression above has an issue with data types.
The problem is the (p[4] << 24) part. The p[4] itself has a type
'uint8_t' which is unsigned 8bit value. It is not enough to hold
the result of a left shift, so compiler automatically promotes it
to the 'int' by default. But it is *signed* 32bit value.
In your original report p[4] was equal to 0x81. After the left
shift it became 0x81000000. Looks correct, but the type is 'int'.
The next operation that we do is '|' with the previous shifted
bytes that were explicitly converted to uint64_t before the left
shift. So we have uint64_t | int. In this case compiler needs
to extend the 'int' to 'unit64_t' before performing the operation.
And since the 'int' is signed and the sign bit happens to be set
in the 0x81000000, the sign extension is performed in order to
preserve the value. The result is 0xffffffff81000000. And that
is breaking everything else.
From the new test below, it is incorrect for the n_bytes counter via
OpenFlow15 on CMD: ovs-ofctl dump-flows.
With the patch, get_unaligned_u64__() will return correct value to
caller on Windows.
In the output (Got via original CMD without fix) below n_bytes
2177130813 will be incorrectly changed to 18446744071591715133 when
processing OpenFlow15 which is equal to 0xFFFFFFFF81C4613D and here
the p[4] on Windows is 0x81.
With the fix, new compiled ovs-ofctl1025.exe could dump the correct
n_bytes counter Via OpenFlow15.
ovs-ofctl.exe -O OpenFlow15 dump-flows nsx-managed | findstr 1516011
cookie=<>, duration=<>s, table=4, n_packets=1516011, n_bytes=18446744071591715133,
cookie=<>, duration=<>s, table=4, n_packets=1516011, n_bytes=18446744071591715133,
ovs-ofctl.exe -O OpenFlow10 dump-flows nsx-managed | findstr 1516011
cookie=<>, duration=<>s, table=4, n_packets=1516011, n_bytes=2177130813,
cookie=<>, duration=<>s, table=4, n_packets=1516011, n_bytes=2177130813,
ovs-ofctl.exe dump-flows nsx-managed | findstr 1516011
cookie=<>, duration=<>s, table=4, n_packets=1516011, n_bytes=2177130813,
cookie=<>, duration=<>s, table=4, n_packets=1516011, n_bytes=2177130813,
With the fix, new compiled ovs-ofctl1025.exe could dump the correct
n_bytes counter Via OpenFlow15.
ovs-ofctl1025.exe -O OpenFlow15 dump-flows nsx-managed | findstr 1516011
cookie=<>, duration=<>s, table=4, n_packets=1516011, n_bytes=2177130813,
cookie=<>, duration=<>s, table=4, n_packets=1516011, n_bytes=2177130813,
Fixes: afa3a93165f1 ("Add header for access to potentially unaligned data.")
Signed-off-by: Wilson Peng <pweisong@vmware.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
This patch removes ct_dpif_format_flags() in favor of the existing
format_flags_masked().
This has the extra bonus of showing keys with empty values as "key=0",
instead of showing "key=".
E.g., the following:
NEW tcp,orig=([...]),reply=([...]),id=1800618864,
status=CONFIRMED|SRC_NAT_DONE|DST_NAT_DONE,timeout=120,
protoinfo=(state_orig=SYN_SENT,state_reply=SYN_SENT,wscale_orig=7,
wscale_reply=0,flags_orig=WINDOW_SCALE|SACK_PERM,flags_reply=)
becomes:
NEW tcp,orig=([...]),reply=([...]),id=1800618864,
status=CONFIRMED|SRC_NAT_DONE|DST_NAT_DONE,timeout=120,
protoinfo=(state_orig=SYN_SENT,state_reply=SYN_SENT,wscale_orig=7,
wscale_reply=0,flags_orig=WINDOW_SCALE|SACK_PERM,flags_reply=0)
Signed-off-by: Paolo Valerio <pvalerio@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Current macros are unable to filter whole seconds, e.g. 'duration:6s'.
This is causing random test failures, most frequently in CirrusCI:
./dpif-netdev.at:370: ovs-ofctl -O OpenFlow13 meter-stats br0 | strip_timers
--- -
+++ /tmp/cirrus-ci-build/tests/testsuite.dir/at-groups/990/stdout
@@ -1,5 +1,5 @@
OFPST_METER reply (OF1.3) (xid=0x2):
-meter:1 flow_count:1 packet_in_count:10 byte_in_count:600 duration:0.0s bands:
+meter:1 flow_count:1 packet_in_count:10 byte_in_count:600 duration:6s bands:
Fix sed matches to correctly handle that scenario.
Repeating the [0-9\.] twice because it is hard to write a shorter
portable version with sed.
Acked-by: Mike Pattrick <mkp@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
OVN can (and indeed does) set in_port to OFPP_NONE during
the pipeline evaluation. If a sample action follows, it
will be incorrectly skipped.
Per-flow sampling version of:
f0a9000ca ofproto: Fix ipfix not always sampling on egress.
Signed-off-by: Adrian Moreno <amorenoz@redhat.com>
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Cited commit introduced a flag in dpif-netdev level, to optimize
performance and avoid hw_miss_packet_recover() for devices with no such
support.
However, there is a race condition between traffic processing and
assigning a 'flow_api' object to the netdev. In such case, EOPNOTSUPP is
returned by netdev_hw_miss_packet_recover() in netdev-offload.c layer
because 'flow_api' is not yet initialized. As a result, the flag is
falsely disabled, and subsequent packets won't be recovered, though they
should.
In order to fix it, move the flag to be in netdev-offload layer, to
avoid that race.
Fixes: 6e50c1651869 ("dpif-netdev: Avoid hw_miss_packet_recover() for devices with no support.")
Signed-off-by: Eli Britstein <elibr@nvidia.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Bucket update in the cmap lib is protected by a counter. But hash setting
is possible to be moved before counter update. This patch fix this issue.
Reviewed-by: Ola Liljedahl <Ola.Liljedahl@arm.com>
Reviewed-by: Gavin Hu <Gavin.Hu@arm.com>
Signed-off-by: Yanqin Wei <Yanqin.Wei@arm.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
The OpenFlow specification says that buckets in select groups with a weight
of zero should not be selected, but the ofproto-dpif implementation could
select them in corner cases. This fixes the problem.
Reported-by: ychen <ychen103103@163.com>
Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2019-May/359349.html
Signed-off-by: Ben Pfaff <blp@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
checkout@v2, cache@v2 and setup-python@v2 are using outdated Node.js 12
which is now deprecated in GHA [1], so these actions will stop working
soon.
Updating to most recent major versions with Node.js 16. This stops GHA
from throwing warnings in every build.
While at it, also updating upload-artifacts to more recent version.
[1] https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/
Acked-by: David Marchand <david.marchand@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Compaction thread supposed to not change anything in the database
it is working on, since the same data can be accessed by the main
thread at the same time. However, while converting database rows
to JSON objects, strings in the datum will be cloned using
json_clone(), which is a shallow copy, and that will change the
reference counter for the JSON string object. If both the main
thread and the compaction thread will clone/destroy the same object
at the same time we may end up with a broken reference counter
leading to a memory leak or use-after free.
Adding a new argument to the database to JSON conversion to prevent
use of shallow copies from the compaction thread. This way all
the database operations will be truly read-only avoiding the race.
'ovsdb_atom_to_json' and 'ovsdb_datum_to_json' are more widely used,
so creating separate variant for these functions instead of adding
a new argument, to avoid changing a lot of existing code.
Other solution might be to use atomic reference counters, but that
will require API/ABI break, because counter is exposed in public
headers. Also, we can not easily expose atomic functions, so we'll
need to un-inline reference counting with the associated performance
cost.
Fixes: 3cd2cbd684e0 ("ovsdb: Prepare snapshot JSON in a separate thread.")
Reported-at: https://bugzilla.redhat.com/2133431
Acked-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
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>
