summaryrefslogtreecommitdiff
path: root/ofproto/ofproto.c
Commit message (Collapse)AuthorAgeFilesLines
* ofproto-dpif-upcall: Wait for valid hw flow stats before applying ↵Eelco Chaudron2023-03-151-0/+10
| | | | | | | | | | | | | | | | | min-revalidate-pps. Depending on the driver implementation, it can take from 0.2 seconds up to 2 seconds before offloaded flow statistics are updated. This is true for both TC and rte_flow-based offloading. This is causing a problem with min-revalidate-pps, as old statistic values are used during this period. This fix will wait for at least 2 seconds, by default, before assuming no packets where received during this period. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Eelco Chaudron <echaudro@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* ofproto: Include flow cookies in bridge/dump-flows output.Viacheslav Galaktionov2023-02-211-0/+4
| | | | | | | | Cookies are an important part of flow descriptions and must be available to the end user. Signed-off-by: Viacheslav Galaktionov <viacheslav.galaktionov@arknetworks.am> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* revalidator: Allow min-revalidator-pps to be 0.Han Zhou2023-01-271-1/+1
| | | | | | | | | | | | | | | | | | | | Today the minimum value for this setting is 1. This patch allows it to be 0, meaning not checking pps at all, and always do revalidation. This is particularly useful for environments where some of the applications with long-lived connections may have very low traffic for certain period but have high rate of burst periodically. It is desirable to keep the datapath flows instead of periodically deleting them to avoid burst of packet miss to userspace. When setting to 0, there may be more datapath flows to be revalidated, resulting in higher CPU cost of revalidator threads. This is the downside but in certain cases this is still more desirable than packet misses to user space. Signed-off-by: Han Zhou <hzhou@ovn.org> Acked-by: Eelco Chaudron <echaudro@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* openflow: Add extension to flush CT by generic match.Ales Musil2023-01-161-1/+28
| | | | | | | | | | | Add extension that allows to flush connections from CT by specifying fields that the connections should be matched against. This allows to match only some fields of the connection e.g. source address for orig direction. Reported-at: https://bugzilla.redhat.com/2120546 Signed-off-by: Ales Musil <amusil@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* treewide: Avoid offsetting NULL pointers.Dumitru Ceara2022-05-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is undefined behavior and was reported by UB Sanitizer: lib/meta-flow.c:3445:16: runtime error: member access within null pointer of type 'struct vl_mf_field' 0 0x6aad0f in mf_get_vl_mff lib/meta-flow.c:3445 1 0x6d96d7 in mf_from_oxm_header lib/nx-match.c:260 2 0x6d9e2e in nx_pull_header__ lib/nx-match.c:341 3 0x6daafa in nx_pull_header lib/nx-match.c:488 4 0x6abcb6 in mf_vl_mff_nx_pull_header lib/meta-flow.c:3605 5 0x73b9be in decode_NXAST_RAW_REG_MOVE lib/ofp-actions.c:2652 6 0x764ccd in ofpact_decode lib/ofp-actions.inc2:4681 [...] lib/sset.c:315:12: runtime error: applying zero offset to null pointer 0 0xcc2e6a in sset_at_position lib/sset.c:315:12 1 0x5734b3 in port_dump_next ofproto/ofproto-dpif.c:4083:20 [...] lib/ovsdb-data.c:2194:56: runtime error: applying zero offset to null pointer 0 0x5e9530 in ovsdb_datum_added_removed lib/ovsdb-data.c:2194:56 1 0x4d6258 in update_row_ref_count ovsdb/transaction.c:335:17 2 0x4c360b in for_each_txn_row ovsdb/transaction.c:1572:33 [...] lib/ofpbuf.c:440:30: runtime error: applying zero offset to null pointer 0 0x75066d in ofpbuf_push_uninit lib/ofpbuf.c:440 1 0x46ac8a in ovnacts_parse lib/actions.c:4190 2 0x46ad91 in ovnacts_parse_string lib/actions.c:4208 3 0x4106d1 in test_parse_actions tests/test-ovn.c:1324 [...] lib/ofp-actions.c:3205:22: runtime error: applying non-zero offset 2 to null pointer 0 0x6e1641 in set_field_split_str lib/ofp-actions.c:3205:22 [...] lib/tnl-ports.c:74:12: runtime error: applying zero offset to null pointer 0 0xceffe7 in tnl_port_cast lib/tnl-ports.c:74:12 1 0xcf14c3 in map_insert lib/tnl-ports.c:116:13 [...] ofproto/ofproto.c:8905:16: runtime error: applying zero offset to null pointer 0 0x556795 in eviction_group_hash_rule ofproto/ofproto.c:8905:16 1 0x503f8d in eviction_group_add_rule ofproto/ofproto.c:9022:42 [...] Also, it's valid to have an empty ofpact list and we should be able to try to iterate through it. UB Sanitizer report: include/openvswitch/ofp-actions.h:222:12: runtime error: applying zero offset to null pointer 0 0x665d69 in ofpact_end ./include/openvswitch/ofp-actions.h:222:12 1 0x66b2cf in ofpacts_put_openflow_actions lib/ofp-actions.c:8861:5 2 0x6ffdd1 in ofputil_encode_flow_mod lib/ofp-flow.c:447:9 [...] Signed-off-by: Dumitru Ceara <dceara@redhat.com> Acked-by: Aaron Conole <aconole@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* ofp-monitor: Support flow monitoring for OpenFlow 1.3, 1.4+.Vasu Dasari2022-04-281-25/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extended OpenFlow monitoring support * OpenFlow 1.3 with ONF extensions * OpenFlow 1.4+ as defined in OpenFlow specification 1.4+. ONF extensions are similar to Nicira extensions except for onf_flow_monitor_request{} where out_port is defined as 32-bit number OF(1.1) number, oxm match formats are used in update and request messages. Flow monitoring support in 1.4+ is slightly different from Nicira and ONF extensions. * More flow monitoring flags are defined. * Monitor add/modify/delete command is introduced in flow_monitor request message. * Addition of out_group as part of flow_monitor request message Description of changes: 1. Generate ofp-msgs.inc to be able to support 1.3, 1.4+ flow Monitoring messages. include/openvswitch/ofp-msgs.h 2. Modify openflow header files with protocol specific headers. include/openflow/openflow-1.3.h include/openflow/openflow-1.4.h 3. Modify OvS abstraction of openflow headers. ofp-monitor.h leverages enums from on nicira extensions for creating protocol abstraction headers. OF(1.4+) enums are superset of nicira extensions. include/openvswitch/ofp-monitor.h 4. Changes to these files reflect encoding and decoding of new protocol messages. lib/ofp-monitor.c 5. Changes to modules using ofp-monitor APIs. Most of the changes here are to migrate enums from nicira to OF 1.4+ versions. ofproto/connmgr.c ofproto/connmgr.h ofproto/ofproto-provider.h ofproto/ofproto.c 6. Extended protocol decoding tests to verify all protocol versions FLOW_MONITOR_CANCEL FLOW_MONITOR_PAUSED FLOW_MONITOR_RESUMED FLOW_MONITOR request FLOW_MONITOR reply tests/ofp-print.at 7. Modify flow monitoring tests to be able executed by all protocol versions. tests/ofproto.at 7. Modified documentation highlighting the change utilities/ovs-ofctl.8.in NEWS Signed-off-by: Vasu Dasari <vdasari@gmail.com> Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2021-June/383915.html Acked-by: Aaron Conole <aconole@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* ofp-monitor: Extend Flow Monitoring support for OF 1.0-1.2 with Nicira ↵Vasu Dasari2022-04-281-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extensions. Currently OVS supports flow-monitoring for OpenFlow 1.0 and Nicira Extenstions. Any other OpenFlow versioned messages are not accepted. This change will allow OpenFlow1.0-1.2 Flow Monitoring with Nicira extensions be accepted. Also made sure that flow-monitoring updates, flow monitoring pause messages, resume messages are sent in the same OpenFlow version as that of flow-monitor request. Description of changes: 1. Generate ofp-msgs.inc to be able to support 1.0-1.2 Flow Monitoring messages. include/openvswitch/ofp-msgs.h 2. Support vconn to accept user specified version and use it for vconn flow-monitoring session ofproto/ofproto.c 3. Modify APIs to use protocol as an argument to encode and decode messages include/openvswitch/ofp-monitor.h lib/ofp-monitor.c ofproto/connmgr.c ofproto/connmgr.h ofproto/ofproto.c 4. Modified following testcases to be verified across supported OF Versions ofproto - flow monitoring ofproto - flow monitoring with !own ofproto - flow monitoring with out_port ofproto - flow monitoring pause and resume ofproto - flow monitoring usable protocols tests/ofproto.at 5. Updated NEWS with the support added with this commit Signed-off-by: Vasu Dasari <vdasari@gmail.com> Reported-at: https://mail.openvswitch.org/pipermail/ovs-discuss/2020-December/050820.html Acked-by: Aaron Conole <aconole@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* hmap: use short version of safe loops if possible.Adrian Moreno2022-03-301-8/+8
| | | | | | | | | | | | | | | Using SHORT version of the *_SAFE loops makes the code cleaner and less error prone. So, use the SHORT version and remove the extra variable when possible for hmap and all its derived types. In order to be able to use both long and short versions without changing the name of the macro for all the clients, overload the existing name and select the appropriate version depending on the number of arguments. Acked-by: Dumitru Ceara <dceara@redhat.com> Acked-by: Eelco Chaudron <echaudro@redhat.com> Signed-off-by: Adrian Moreno <amorenoz@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* ofproto: Add refcount to ofproto to fix ofproto use-after-free.Peng He2022-03-071-5/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | From hepeng: https://patchwork.ozlabs.org/project/openvswitch/patch/20200717015041.82746-1-hepeng.0320@bytedance.com/#2487473 also from guohongzhi <guohongzhi1@huawei.com>: http://patchwork.ozlabs.org/project/openvswitch/patch/20200306130555.19884-1-guohongzhi1@huawei.com/ also from a discussion about the mixing use of RCU and refcount in the mail list with Ilya Maximets, William Tu, Ben Pfaf, and Gaëtan Rivet. A summary, as quoted from Ilya: " RCU for ofproto was introduced for one and only one reason - to avoid freeing ofproto while rules are still alive. This was done in commit f416c8d61601 ("ofproto: RCU postpone rule destruction."). The goal was to allow using rules without refcounting them within a single grace period. And that forced us to postpone destruction of the ofproto for a single grace period. Later commit 39c9459355b6 ("Use classifier versioning.") made it possible for rules to be alive for more than one grace period, so the commit made ofproto wait for 2 grace periods by double postponing. As we can see now, that wasn't enough and we have to wait for more than 2 grace periods in certain cases. " In a short, the ofproto should have a longer life time than rule, if the rule lasts for more than 2 grace periods, the ofproto should live longer to ensure rule->ofproto is valid. It's hard to predict how long a ofproto should live, thus we need to use refcount on ofproto to make things easy. The controversial part is that we have already used RCU postpone to delay ofproto destrution, if we have to add refcount, is it simpler to use just refcount without RCU postpone? IMO, I think going back to the pure refcount solution is more complicated than mixing using both. Gaëtan Rive asks some questions on guohongzhi's v2 patch: during ofproto_rule_create, should we use ofproto_ref or ofproto_try_ref? how can we make sure the ofproto is alive? By using RCU, ofproto has three states: state 1: alive, with refcount >= 1 state 2: dying, with refcount == 0, however pointer is valid state 3: died, memory freed, pointer might be dangling. Without using RCU, there is no state 2, thus, we have to be very careful every time we see a ofproto pointer. In contrast, with RCU, we can be sure that it's alive at least in this grace peroid, so we can just check if it is dying by ofproto_try_ref. This shows that by mixing use of RCU and refcount we can save a lot of work worrying if ofproto is dangling. In short, the RCU part makes sure the ofproto is alive when we use it, and the refcount part makes sure it lives longer enough. In this patch, I have merged guohongzhi's patch and mine, and fixes accoring to the previous comments. Acked-by: Adrian Moreno <amorenoz@redhat.com> Acked-by: Gaetan Rivet <grive@u256.net> Acked-by: Mike Pattrick <mkp@redhat.com> Acked-by: Alin-Gabriel Serdean <aserdean@ovn.org> Tested-by: Alin-Gabriel Serdean <aserdean@ovn.org> Signed-off-by: Peng He <hepeng.0320@bytedance.com> Co-authored-by: Hongzhi Guo <guohongzhi1@huawei.com> Signed-off-by: Hongzhi Guo <guohongzhi1@huawei.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* ofproto: Fix resource usage explosion due to removal of large number of flows.Ilya Maximets2021-11-301-2/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While removing flows, removal itself is deferred, so classifier changes performed already from the RCU thread. This way every deferred removal triggers classifier change and reallocation of a pvector. Freeing of old version of a pvector is postponed. Since all this is happening from an RCU thread, all these copies of the same pvector will be freed only after the next grace period. Below is the example output of the 'valgrind --tool=massif' from an OVN deployment, where copies of that pvector took 5 GB of memory while processing a bundled flow removal: ------------------------------------------------------------------- n time(i) total(B) useful-heap(B) extra-heap(B) ------------------------------------------------------------------- 89 176,257,987,954 5,329,763,160 5,318,171,607 11,591,553 99.78% (5,318,171,607B) (heap allocation functions) malloc/new/new[] ->98.45% (5,247,008,392B) xmalloc__ (util.c:137) |->98.17% (5,232,137,408B) pvector_impl_dup (pvector.c:48) ||->98.16% (5,231,472,896B) pvector_remove (pvector.c:159) |||->98.16% (5,231,472,800B) destroy_subtable (classifier.c:1558) ||||->98.16% (5,231,472,800B) classifier_remove (classifier.c:792) |||| ->98.16% (5,231,472,800B) classifier_remove_assert (classifier.c:832) |||| ->98.16% (5,231,472,800B) remove_rule_rcu__ (ofproto.c:2978) |||| ->98.16% (5,231,472,800B) remove_rule_rcu (ofproto.c:2990) |||| ->98.16% (5,231,472,800B) ovsrcu_call_postponed (ovs-rcu.c:346) |||| ->98.16% (5,231,472,800B) ovsrcu_postpone_thread (ovs-rcu.c:362) |||| ->98.16% (5,231,472,800B) ovsthread_wrapper |||| ->98.16% (5,231,472,800B) start_thread |||| ->98.16% (5,231,472,800B) clone Collecting all the flows to be removed and postponing removal for all of them together to avoid the problem. This way all removals will trigger only a single pvector re-allocation greatly reducing the CPU and memory usage. Reported-by: Vladislav Odintsov <odivlad@gmail.com> Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2021-November/389538.html Tested-by: Vladislav Odintsov <odivlad@gmail.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* ofproto: Fix resource usage explosion while processing bundled FLOW_MOD.Ilya Maximets2021-11-301-0/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While processing a bundle, OVS will add all new and modified rules to classifiers. Classifiers are using RCU-protected pvector to store subtables. Addition of a new subtable or removal of the old one leads to re-allocation and memory copy of the pvector array. Old version of that array is given to RCU thread to free it later. The problem is that bundle is processed under the mutex without entering the quiescent state. Therefore, memory can not be freed until the whole bundle is processed. So, if a few thousands of flows added to the same table in a bundle, pvector will be re-allocated while adding each of them. So, we'll have a few thousands of copies of the same array waiting to be freed. In case of OVN deployments, there could be hundreds of thousands of flows in the same table leading to a fast consumption of a huge amount of memory and wasting a lot of CPU cycles on allocations and copies. Below snippet of the 'valgrind --tool=massif' output shows ovs-vswitchd consuming 3.5GB of RAM while processing a bundle with 65K FLOW_MODs in the OVN deployment. 3.4GB of that memory are copies of the same pvector. ------------------------------------------------------------------- n time(i) total(B) useful-heap(B) extra-heap(B) ------------------------------------------------------------------- 64 109,907,465,404 3,559,987,568 3,546,879,748 13,107,820 99.63% (3,546,879,748B) (heap allocation functions) malloc/new/new[] ->97.61% (3,474,750,333B) xmalloc__ (util.c:137) |->97.61% (3,474,750,333B) xmalloc (util.c:172) | ->96.38% (3,431,068,352B) pvector_impl_dup (pvector.c:48) || ->96.38% (3,431,067,840B) pvector_insert (pvector.c:138) || |->96.38% (3,431,067,840B) classifier_replace (classifier.c:664) || | ->96.38% (3,431,067,840B) classifier_insert (classifier.c:695) || | ->96.38% (3,431,067,840B) replace_rule_start (ofproto.c:5563) || | ->96.38% (3,431,067,840B) add_flow_start (ofproto.c:5179) || | ->96.38% (3,431,067,840B) ofproto_flow_mod_start (ofproto.c:8017) || | ->96.38% (3,431,067,744B) do_bundle_commit (ofproto.c:8168) || | |->96.38% (3,431,067,744B) handle_bundle_control (ofproto.c:8309) || | | ->96.38% (3,431,067,744B) handle_single_part_openflow (ofproto.c:8593) || | | ->96.38% (3,431,067,744B) handle_openflow (ofproto.c:8674) || | | ->96.38% (3,431,067,744B) ofconn_run (connmgr.c:1329) || | | ->96.38% (3,431,067,744B) connmgr_run (connmgr.c:356) || | | ->96.38% (3,431,067,744B) ofproto_run (ofproto.c:1879) || | | ->96.38% (3,431,067,744B) bridge_run__ (bridge.c:3251) || | | ->96.38% (3,431,067,744B) bridge_run (bridge.c:3310) || | | ->96.38% (3,431,067,744B) main (ovs-vswitchd.c:127) Fixing that by postponing the publishing of classifier updates, so each flow modification can work with the same version of pvector. Unfortunately, bundled PACKET_OUT messages requires all previous changes to be published before processing, otherwise the packet will use wrong version of OF tables. Publishing all changes before processing PACKET_OUT messages to avoid this issue. Hopefully, mixup of a big number of FLOW_MOD and PACKET_OUT messages is not a common usecase. Reported-by: Vladislav Odintsov <odivlad@gmail.com> Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2021-November/389503.html Tested-by: Vladislav Odintsov <odivlad@gmail.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* dpif-netlink: Introduce per-cpu upcall dispatch.Mark Gray2021-07-161-12/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Open vSwitch kernel module uses the upcall mechanism to send packets from kernel space to user space when it misses in the kernel space flow table. The upcall sends packets via a Netlink socket. Currently, a Netlink socket is created for every vport. In this way, there is a 1:1 mapping between a vport and a Netlink socket. When a packet is received by a vport, if it needs to be sent to user space, it is sent via the corresponding Netlink socket. This mechanism, with various iterations of the corresponding user space code, has seen some limitations and issues: * On systems with a large number of vports, there is correspondingly a large number of Netlink sockets which can limit scaling. (https://bugzilla.redhat.com/show_bug.cgi?id=1526306) * Packet reordering on upcalls. (https://bugzilla.redhat.com/show_bug.cgi?id=1844576) * A thundering herd issue. (https://bugzilla.redhat.com/show_bug.cgi?id=1834444) This patch introduces an alternative, feature-negotiated, upcall mode using a per-cpu dispatch rather than a per-vport dispatch. In this mode, the Netlink socket to be used for the upcall is selected based on the CPU of the thread that is executing the upcall. In this way, it resolves the issues above as: a) The number of Netlink sockets scales with the number of CPUs rather than the number of vports. b) Ordering per-flow is maintained as packets are distributed to CPUs based on mechanisms such as RSS and flows are distributed to a single user space thread. c) Packets from a flow can only wake up one user space thread. Reported-at: https://bugzilla.redhat.com/1844576 Signed-off-by: Mark Gray <mark.d.gray@redhat.com> Acked-by: Flavio Leitner <fbl@sysclose.org> Acked-by: Aaron Conole <aconole@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* ofproto: Change type of n_handlers and n_revalidators.Mark Gray2021-07-161-1/+1
| | | | | | | | | | | 'n_handlers' and 'n_revalidators' are declared as type 'size_t'. However, dpif_handlers_set() requires parameter 'n_handlers' as type 'uint32_t'. This patch fixes this type mismatch. Signed-off-by: Mark Gray <mark.d.gray@redhat.com> Acked-by: Flavio Leitner <fbl@sysclose.org> Acked-by: Aaron Conole <aconole@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* ofproto: Fix potential NULL dereference in ofproto_ct_*_zone_timeout_policy().Dumitru Ceara2021-06-031-2/+2
| | | | | | | | | Spotted during code inspection. Fixes: 993cae678bca ("ofproto-dpif: Consume CT_Zone, and CT_Timeout_Policy tables") Signed-off-by: Dumitru Ceara <dceara@redhat.com> Acked-by: Paolo Valerio <pvalerio@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* ofproto: Fix potential NULL dereference in ofproto_get_datapath_cap().Dumitru Ceara2021-06-031-1/+1
| | | | | | | | | | | | | | Reproducer: ovs-vsctl \ -- add-br br \ -- set bridge br datapath-type=foo \ -- --id=@m create Datapath datapath_version=0 'capabilities={}' \ -- set Open_vSwitch . datapaths:"foo"=@m Fixes: 27501802d09f ("ofproto-dpif: Expose datapath capability to ovsdb.") Signed-off-by: Dumitru Ceara <dceara@redhat.com> Acked-by: Paolo Valerio <pvalerio@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* Eliminate use of term "slave" in bond, LACP, and bundle contexts.Ben Pfaff2020-10-211-3/+4
| | | | | | | | | | | | | The new term is "member". Most of these changes should not change user-visible behavior. One place where they do is in "ovs-ofctl dump-flows", which will now output "members:..." inside "bundle" actions instead of "slaves:...". I don't expect this to cause real problems in most systems. The old syntax is still supported on input for backward compatibility. Signed-off-by: Ben Pfaff <blp@ovn.org> Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
* Use primary/secondary, not master/slave, as names for OpenFlow roles.Ben Pfaff2020-10-161-18/+18
| | | | | Signed-off-by: Ben Pfaff <blp@ovn.org> Acked-by: Alin Gabriel Serdean <aserdean@ovn.org>
* ofproto: Fix statistics of removed flow.Ilya Maximets2020-05-151-2/+2
| | | | | | | | | 'fr' is a new variable on the stack. '+=' here adds the real statistics to a random stack memory. Fixes: 164413156cf9 ("Add offload packets statistics") Acked-by: Roi Dayan <roid@mellanox.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* ofproto: Add support to watch controller port liveness in fast-failover groupVishal Deep Ajmera2020-03-061-1/+2
| | | | | | | | | | | | | | | | | | | | Currently fast-failover group does not support checking liveness of controller port (OFPP_CONTROLLER). However this feature can be useful for selecting alternate pipeline when controller connection itself is down for e.g. by using local DHCP server to reply for any DHCP request originating from VMs. This patch adds the support for watching controller port liveness in fast- failover group. Controller port is considered live when atleast one of-connection is alive. Example usage: ovs-ofctl add-group br-int 'group_id=1234,type=ff, bucket=watch_port:CONTROLLER,actions:<A>, bucket=watch_port:1,actions:<B> Signed-off-by: Vishal Deep Ajmera <vishal.deep.ajmera@ericsson.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* vswitchd: Add serial number configuration.Kirill A. Kornilov2020-01-311-0/+7
| | | | | Signed-off-by: Kirill A. Kornilov <kornilov@zelax.ru> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ofproto: Do not delete datapath flows on exit by default.Ben Pfaff2020-01-241-4/+4
| | | | | | | | | | | | | Commit e96a5c24e853 ("upcall: Remove datapath flows when setting n-threads.") caused OVS to delete datapath flows when it exits through any graceful means. This is not necessarily desirable, especially when OVS is being stopped as part of an upgrade. This commit changes OVS so that it only removes datapath flows when requested, via "ovs-appctl exit --cleanup". Acked-by: Numan Siddique <numans@ovn.org> Tested-by: Numan Siddique <numans@ovn.org> Signed-off-by: Ben Pfaff <blp@ovn.org>
* Add offload packets statisticszhaozhanxu2019-12-061-22/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add argument '--offload-stats' for command ovs-appctl bridge/dump-flows to display the offloaded packets statistics. The commands display as below: orignal command: ovs-appctl bridge/dump-flows br0 duration=574s, n_packets=1152, n_bytes=110768, priority=0,actions=NORMAL table_id=254, duration=574s, n_packets=0, n_bytes=0, priority=2,recirc_id=0,actions=drop table_id=254, duration=574s, n_packets=0, n_bytes=0, priority=0,reg0=0x1,actions=controller(reason=) table_id=254, duration=574s, n_packets=0, n_bytes=0, priority=0,reg0=0x2,actions=drop table_id=254, duration=574s, n_packets=0, n_bytes=0, priority=0,reg0=0x3,actions=drop new command with argument '--offload-stats' Notice: 'n_offload_packets' are a subset of n_packets and 'n_offload_bytes' are a subset of n_bytes. ovs-appctl bridge/dump-flows --offload-stats br0 duration=582s, n_packets=1152, n_bytes=110768, n_offload_packets=1107, n_offload_bytes=107992, priority=0,actions=NORMAL table_id=254, duration=582s, n_packets=0, n_bytes=0, n_offload_packets=0, n_offload_bytes=0, priority=2,recirc_id=0,actions=drop table_id=254, duration=582s, n_packets=0, n_bytes=0, n_offload_packets=0, n_offload_bytes=0, priority=0,reg0=0x1,actions=controller(reason=) table_id=254, duration=582s, n_packets=0, n_bytes=0, n_offload_packets=0, n_offload_bytes=0, priority=0,reg0=0x2,actions=drop table_id=254, duration=582s, n_packets=0, n_bytes=0, n_offload_packets=0, n_offload_bytes=0, priority=0,reg0=0x3,actions=drop Signed-off-by: zhaozhanxu <zhaozhanxu@163.com> Signed-off-by: Simon Horman <simon.horman@netronome.com>
* ofproto: Fix crash on PACKET_OUT due to recursive locking after upcall.Ilya Maximets2019-11-261-4/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Handling of OpenFlow PACKET_OUT implies pushing the packet through the datapath and packet processing inside the datapath could trigger an upcall. In case of system datapath, 'dpif_execute()' sends packet to the kernel module and returns. If any, upcall will be triggered inside the kernel and handled by a separate thread in userspace. But in case of userspace datapath full processing of the packet happens inside the 'dpif_execute()' in the same thread that handled PACKET_OUT. This causes an issue if upcall will lead to modification of flow rules. For example, it could happen while processing of 'learn' actions. Since whole handling of PACKET_OUT is protected by 'ofproto_mutex', OVS will assert on attempt to take it recursively while processing 'learn' actions: 0 __GI_raise (sig=sig@entry=6) 1 __GI_abort () 2 ovs_abort_valist () 3 ovs_abort () 4 ovs_mutex_lock_at (where=where@entry=0xad4199 "ofproto/ofproto.c:5391") <Trying to acquire ofproto_mutex again> 5 ofproto_flow_mod_learn () at ofproto/ofproto.c:5391 <Trying to modify flows according to 'learn' action> 6 xlate_learn_action () at ofproto/ofproto-dpif-xlate.c:5378 <'learn' action found> 7 do_xlate_actions () at ofproto/ofproto-dpif-xlate.c:6893 8 xlate_recursively () at ofproto/ofproto-dpif-xlate.c:4233 9 xlate_table_action () at ofproto/ofproto-dpif-xlate.c:4361 10 in xlate_ofpact_resubmit () at ofproto/ofproto-dpif-xlate.c:4672 11 do_xlate_actions () at ofproto/ofproto-dpif-xlate.c:6773 12 xlate_actions () at ofproto/ofproto-dpif-xlate.c:7570 <Translating actions> 13 upcall_xlate () at ofproto/ofproto-dpif-upcall.c:1197 14 process_upcall () at ofproto/ofproto-dpif-upcall.c:1413 15 upcall_cb () at ofproto/ofproto-dpif-upcall.c:1315 16 dp_netdev_upcall (DPIF_UC_MISS) at lib/dpif-netdev.c:6236 <Flow cache miss. Making upcall> 17 handle_packet_upcall () at lib/dpif-netdev.c:6591 18 fast_path_processing () at lib/dpif-netdev.c:6709 19 dp_netdev_input__ () at lib/dpif-netdev.c:6797 20 dp_netdev_recirculate () at lib/dpif-netdev.c:6842 21 dp_execute_cb () at lib/dpif-netdev.c:7158 22 odp_execute_actions () at lib/odp-execute.c:794 23 dp_netdev_execute_actions () at lib/dpif-netdev.c:7332 24 dpif_netdev_execute () at lib/dpif-netdev.c:3725 25 dpif_netdev_operate () at lib/dpif-netdev.c:3756 <Packet pushed to userspace datapath for processing> 26 dpif_operate () at lib/dpif.c:1367 27 dpif_execute () at lib/dpif.c:1321 28 packet_execute () at ofproto/ofproto-dpif.c:4760 29 ofproto_packet_out_finish () at ofproto/ofproto.c:3594 <Taking ofproto_mutex> 30 handle_packet_out () at ofproto/ofproto.c:3635 31 handle_single_part_openflow (OFPTYPE_PACKET_OUT) at ofproto/ofproto.c:8400 32 handle_openflow () at ofproto/ofproto.c:8587 33 ofconn_run () 34 connmgr_run () 35 ofproto_run () 36 bridge_run__ () 37 bridge_run () 38 main () Fix that by splitting the 'ofproto_packet_out_finish()' in two parts. First one that translates side-effects and requires holding 'ofproto_mutex' and the second that only pushes packet to datapath. The second part moved out of 'ofproto_mutex' because 'ofproto_mutex' is not required and actually should not be taken in order to avoid recursive locking. Reported-by: Anil Kumar Koli <anilkumar.k@altencalsoftlabs.com> Reported-at: https://mail.openvswitch.org/pipermail/ovs-discuss/2019-April/048494.html Signed-off-by: Ilya Maximets <i.maximets@ovn.org> Acked-by: Ben Pfaff <blp@ovn.org>
* ofproto-dpif: Expose datapath capability to ovsdb.William Tu2019-11-211-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The patch adds support for fetching the datapath's capabilities from the result of 'check_support()', and write the supported capability to a new database column, called 'capabilities' under Datapath table. To see how it works, run: # ovs-vsctl -- add-br br0 -- set Bridge br0 datapath_type=netdev # ovs-vsctl -- --id=@m create Datapath datapath_version=0 \ 'ct_zones={}' 'capabilities={}' \ -- set Open_vSwitch . datapaths:"netdev"=@m # ovs-vsctl list-dp-cap netdev ufid=true sample_nesting=true clone=true tnl_push_pop=true \ ct_orig_tuple=true ct_eventmask=true ct_state=true \ ct_clear=true max_vlan_headers=1 recirc=true ct_label=true \ max_hash_alg=1 ct_state_nat=true ct_timeout=true \ ct_mark=true ct_orig_tuple6=true check_pkt_len=true \ masked_set_action=true max_mpls_depth=3 trunc=true ct_zone=true Signed-off-by: William Tu <u9012063@gmail.com> Tested-by: Greg Rose <gvrose8192@gmail.com> Reviewed-by: Greg Rose <gvrose8192@gmail.com> --- v5: Add improved documentation from Ben and fix checkpatch error (tab and line 79 char) v4: rebase to master v3: fix 32-bit build, reported by Greg travis: https://travis-ci.org/williamtu/ovs-travis/builds/599276267 v2: rebase to master
* lldp: Fix for OVS crashes when a LLDP-enabled port is deletedSurya Rudra2019-10-241-0/+3
| | | | | | | | | | | | | | | | | | | Issue: When LLDP is enabled on a port, a structure to hold LLDP related state is created and that structure has a reference to the port. The ofproto monitor thread accesses the LLDP structure to periodically send packets over the associated port. When the port is deleted, the LLDP structure is not cleaned up and it continues to refer to the deleted port. When the monitor thread attempts to access the deleted port OVS crashes. Crash can happen with bridge delete and bond delete also. Fix: Remove all references to the LLDP structure and free it when the port is deleted. Signed-off-by: Surya Rudra <rudrasurya.r@altencalsoftlabs.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ofproto-dpif: Consume CT_Zone, and CT_Timeout_Policy tablesYi-Hung Wei2019-09-261-0/+26
| | | | | | | | | | | | | | | | | | | | | | | This patch consumes the CT_Zone and CT_Timeout_Policy tables, maintains the zone-based configuration in the vswitchd. Whenever there is a database change, vswitchd will read the datapath, CT_Zone, and CT_Timeout_Policy tables from ovsdb, builds an internal snapshot of the database configuration in bridge.c, and pushes down the change into ofproto and dpif layer. If a new zone-based timeout policy is added, it updates the zone to timeout policy mapping in the per datapath type datapath structure in dpif-backer, and pushes down the timeout policy into the datapath via dpif interface. If a timeout policy is no longer used, for kernel datapath, vswitchd may not be able to remove it from datapath immediately since datapath flows can still reference the to-be-deleted timeout policies. Thus, we keep an timeout policy kill list, that vswitchd will go back to the list periodically and try to kill the unused timeout policies. Signed-off-by: Yi-Hung Wei <yihung.wei@gmail.com> Signed-off-by: Justin Pettit <jpettit@ovn.org>
* upcall: Configure datapath min-revalidate-pps through ovs-vsctl.Vlad Buslov2019-08-211-0/+9
| | | | | | | | | | | This patch adds a new configuration option, "min-revalidate-pps" to the Open_vSwitch "other-config" column. This sets minimum pps that flow must have in order to be revalidated when revalidation duration exceeds half of max-revalidator config variable. Signed-off-by: Vlad Buslov <vladbu@mellanox.com> Acked-by: Roi Dayan <roid@mellanox.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* upcall: Configure datapath max-revalidator through ovs-vsctl.Vlad Buslov2019-08-211-0/+10
| | | | | | | | | | | This patch adds a new configuration option, "max-revalidator" to the Open_vSwitch "other-config" column. This sets maximum allowed ravalidator timeout. Actual timeout value is determined at runtime as minimum of "max-idle" and "max-revalidator". Signed-off-by: Vlad Buslov <vladbu@mellanox.com> Acked-by: Roi Dayan <roid@mellanox.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ofproto: Return error codes for rule insertions.Aravind Prasad S2019-04-231-29/+80
| | | | | | | | | | | | | | | | | | | | | | | | Currently, rule_insert() API does not have return value. There are some possible scenarios where rule insertions can fail at run-time even though the static checks during rule_construct() had passed previously. Some possible scenarios for failure of rule insertions: **) Rule insertions can fail dynamically in Hybrid mode (both Openflow and Normal switch functioning coexist) where the CAM space could get suddenly filled up by Normal switch functioning and Openflow gets devoid of available space. **) Some deployments could have separate independent layers for HW rule insertions and application layer to interact with OVS. HW layer could face any dynamic issue during rule handling which application could not have predicted/captured in rule-construction phase. Rule-insert errors for bundles are handled too. Testing: Tested failures of rule insertions and also with bundles. Signed-off-by: Aravind Prasad S <aravind.sridharan at dell.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* bridge: Propagate patch port pairing errors to db.Ilya Maximets2019-03-261-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Virtual ports like 'patch' ports that almost fully implemented on 'ofproto' layer could have internal to 'ofproto' statuses that could not be retrieved from 'netdev' or other layers. For example, in current implementation there is no way to get the patch port pairing status (i.e. if it has usable peer?). New 'ofproto-provider' API function 'vport_get_status' introduced to cover this gap. It allowes 'bridge' layer to retrive current status of ofproto virtual ports and propagate it to DB. For now we're only interested in pairing errors of 'patch' ports. That are propagated to the 'error' column of the 'Interface' table. Ex.: $ ovs-vsctl show ... Bridge "br1" ... Port "patch1" Interface "patch1" type: patch options: {peer="patch0"} error: "No usable peer 'patch0' exists in 'system' datapath." Bridge "br0" datapath_type: netdev ... Port "patch0" Interface "patch0" type: patch options: {peer="patch1"} error: "No usable peer 'patch1' exists in 'netdev' datapath." Acked-by: Eelco Chaudron <echaudro@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@samsung.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ofproto: fix the bug of bucket counter is not updatedLi Wei2019-03-251-0/+2
| | | | | | | | | | | | | | | | | | After inserting/removing a bucket, we don't update the bucket counter. When we call ovs-ofctl dump-group-stats br-int, a panic happened. Reproduce steps: 1. ovs-ofctl -O OpenFlow15 add-group br-int "group_id=1, type=select, selection_method=hash bucket=bucket_id=1,weight:100,actions=output:1" 2. ovs-ofctl insert-buckets br-int "group_id=1, command_bucket_id=last, bucket=bucket_id=7,weight:800,actions=output:1" 3. ovs-ofctl dump-group-stats br-int gdb) bt at ../sysdeps/posix/libc_fatal.c:175 ar_ptr=<optimized out>) at malloc.c:5049 group_id=<optimized out>, cb=cb@entry=0x55cab8fd6cd0 <append_group_stats>) at ofproto/ofproto.c:6790 Signed-off-by: solomon <liwei.solomon@gmail.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ofproto: Fix for ovs-vswitchd crash on flow-mod with unsupported actionparameswaran krishnamurthy2019-03-051-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem Description: The ovs-vswitchd is crashing while invoking flow-mod with upsupported action(Tested with ovs2.10.1) Steps to recreate: Step 1) Create a flow ovs-ofctl add-flow switch1 priority=228,dl_type=0x0800,dl_vlan="600",in_port=25,actions=output:ALL This step is successful. Step 2) Invoke flow-mod with incorrect contents. ovs-ofctl mod-flows switch1 priority=228,dl_type=0x0800,dl_vlan="600",in_port=25,actions=output:ALL,mod_vlan_vid:50,mod_vlan_pcp=6,mod_nw_tos=16 In the above example, the ofproto provider I have, will return error for rule_construct as set_fields come after Output. However the OVS is ignoring the error (The return value of add_flow_init is ignored in modify_flow_init_strict) and eventually the ovs-vswitched crashes. Crash backtrace: ----------------------- Thread 1 "ovs-vswitchd" received signal SIGSEGV, Segmentation fault. 0x00007f6a06e785fb in modify_flows_start__ ( ofproto=ofproto@entry=0x55b289cecc28, ofm=ofm@entry=0x7ffdf7d57b70) at ofproto/ofproto.c:5402 5402 in ofproto/ofproto.c (gdb) bt #0 0x00007f6a06e785fb in modify_flows_start__ ( ofproto=ofproto@entry=0x55b289cecc28, ofm=ofm@entry=0x7ffdf7d57b70) at ofproto/ofproto.c:5402 #1 0x00007f6a06e790db in modify_flows_start_loose (ofm=0x7ffdf7d57b70, ofproto=0x55b289cecc28) at ofproto/ofproto.c:5443 #2 ofproto_flow_mod_start (ofproto=ofproto@entry=0x55b289cecc28, ofm=ofm@entry=0x7ffdf7d57b70) at ofproto/ofproto.c:7672 #3 0x00007f6a06e79164 in handle_flow_mod__ ( ofproto=ofproto@entry=0x55b289cecc28, fm=fm@entry=0x7ffdf7d57d20, req=req@entry=0x7ffdf7d57cd0) at ofproto/ofproto.c:5858 #4 0x00007f6a06e792c2 in handle_flow_mod (ofconn=ofconn@entry =0x55b289d528c0, oh=oh@entry=0x55b289d5a410) at ofproto/ofproto.c:5835 #5 0x00007f6a06e7a173 in handle_openflow__ (msg=0x55b289d351d0, ofconn=0x55b289d528c0) at ofproto/ofproto.c:8127 #6 handle_openflow (ofconn=0x55b289d528c0, ofp_msg=0x55b289d351d0) at ofproto/ofproto.c:8296 #7 0x00007f6a06e6a013 in ofconn_run ( handle_openflow=0x7f6a06e796f0 <handle_openflow>, ofconn=0x55b289d528c0) at ofproto/connmgr.c:1446 #8 connmgr_run (mgr=0x55b289d14fe0, handle_openflow=handle_openflow@entry=0x7f6a06e796f0 handle_openflow>) at ofproto/connmgr.c:365 With this fix, OVS does not crash. Signed-off-by: Parameswaran Krishnamurthy <parkrish@gmail.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ofproto: Don't always treat passive controllers as "equal".Ben Pfaff2019-02-051-2/+1
| | | | | | | | | If a passive controller chooses to configure itself as a slave controller, I don't know a reason why it should be considered "equal" for some purposes. Acked-by: Justin Pettit <jpettit@ovn.org> Signed-off-by: Ben Pfaff <blp@ovn.org>
* vswitchd: Allow user to configure controllers as "primary" or "service".Ben Pfaff2019-02-051-0/+6
| | | | | | | | | | | | | | Normally it makes sense for an active connection to be primary and a passive connection to be a service connection, but I've run into a corner case where it is better for a passive connection to be a primary connection. This specific case is for use with OFtest, which expects to be a primary controller. However, it also wants to reconnect frequently, which is slow for active connections because of the backoff; by configuring a passive, primary controller, OFtest can reconnect as frequently and as quickly as it wants, making the overall test much faster. Acked-by: Justin Pettit <jpettit@ovn.org> Signed-off-by: Ben Pfaff <blp@ovn.org>
* Remove support for OpenFlow 1.6 (draft).Ben Pfaff2019-02-051-4/+1
| | | | | | | | | ONF abandoned the OpenFlow specification, so that OpenFlow 1.6 will never be completed. It did not contain much in the way of useful features, so remove what support Open vSwitch already had. Signed-off-by: Ben Pfaff <blp@ovn.org> Acked-by: Justin Pettit <jpettit@ovn.org>
* ofproto: Handle flow monitor requests with multiple parts.Ben Pfaff2019-01-151-43/+46
| | | | | Acked-by: Justin Pettit <jpettit@ovn.org> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ovs-vswitchd: Implement OFPT_TABLE_FEATURES table modification request.Ben Pfaff2019-01-151-25/+259
| | | | | | | | | This allows a controller to change the name of OpenFlow flow tables in the OVS software switch. CC: Brad Cowie <brad@cowie.nz> Acked-by: Justin Pettit <jpettit@ovn.org> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ofproto: Handle multipart requests with multiple parts.Ben Pfaff2019-01-101-22/+19
| | | | | | | | | | | | | | | OpenFlow has a concept of multipart messages, that is, messages that can be broken into multiple pieces that are sent separately. Before OpenFlow 1.3, only replies could actually have multiple pieces. OpenFlow 1.3 introduced the idea that requests could have multiple pieces. This is only useful for multipart requests that take an array as part of the request, which amounts to only flow monitoring requests and table features requests. So far, OVS hasn't implemented the multipart versions of these (it just reports an error). This commit introduces the necessary infastructure to implement them properly. Acked-by: Justin Pettit <jpettit@ovn.org> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ofproto.c: Handle the situation when ofp_port number exhausted.Han Zhou2018-11-091-13/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | When ofp_port number is exhausted, OFPP_NONE (65535) will be returned by alloc_ofp_port(). In this case we should error out instead of continue using 65535 as port number. Using the invalid number causes unpredictable consequences: 2018-11-06T01:29:10.042Z|142103|dpif(ovs-vswitchd)|WARN|system@ovs-system: failed to add ovn-aded97-0 as port: Device or resource busy 2018-11-06T01:29:10.045Z|142104|bridge(ovs-vswitchd)|INFO|bridge br-int: added interface ovn-aded97-0 on port 65535 2018-11-06T01:29:11.479Z|142108|ofproto(ovs-vswitchd)|WARN|br-int: cannot configure bfd on nonexistent port 65535 2018-11-06T01:29:11.479Z|142109|ofproto(ovs-vswitchd)|WARN|br-int: cannot configure LLDP on nonexistent port 65535 2018-11-06T01:29:11.479Z|142110|ofproto(ovs-vswitchd)|WARN|br-int: cannot configure datapath on nonexistent port 65535 ... 2018-11-06T01:29:18.783Z|142117|bfd(ovs-vswitchd)|INFO|ovn-aded97-0: BFD state change: admin_down->down "No Diagnostic"->"No Diagnostic". 2018-11-06T01:29:18.785Z|00061|bfd(monitor82)|INFO|Interface ovn-aded97-0 remote mult value 0 changed to 3 2018-11-06T01:29:18.785Z|00062|bfd(monitor82)|INFO|ovn-aded97-0: New remote min_rx. ... 2018-11-06T01:29:18.773Z|142111|bridge(ovs-vswitchd)|INFO|bridge br-int: deleted interface ovn-aded97-0 on port 65535 ... 2018-11-06T01:29:18.779Z|142115|dpif(ovs-vswitchd)|WARN|system@ovs-system: failed to add ovn-aded97-0 as port: Device or resource busy 2018-11-06T01:29:18.782Z|142116|bridge(ovs-vswitchd)|INFO|bridge br-int: added interface ovn-aded97-0 on port 65535 ... 2018-11-06T01:29:18.785Z|00064|bfd(monitor82)|WARN|ovn-aded97-0: Incorrect your_disc. ... Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ofproto.c: Fix port number leaking.Han Zhou2018-11-091-1/+1
| | | | | | | | | | | | When there is an error in ofport_install(), the ofp port number is not deallocated, which leads to port number leak. For example, when there is an redundant tunnel port added in an OVS bridge, ovs-vswitchd will try to add the port to ofproto whenever OVSDB changes, which would trigger the port number leak, and over the time there won't be any port available for valid requests. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* connmgr: Improve interface for setting controllers.Ben Pfaff2018-10-311-5/+2
| | | | | | | | | | | Using an shash instead of an array simplifies the code for both the caller and the callee. Putting the set of allowed OpenFlow versions into the ofproto_controller data structure also simplifies the overall function interface slightly. Tested-by: Yifeng Sun <pkusunyifeng@gmail.com> Reviewed-by: Yifeng Sun <pkusunyifeng@gmail.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ofproto: Consistently force off OFPPS_LIVE if port or link is down.Ben Pfaff2018-10-181-10/+33
| | | | | | | | It doesn't make sense for a port that is down to be "live" from OpenFlow's point of view, but this could happen in OVS. Signed-off-by: Ben Pfaff <blp@ovn.org> Acked-by: Numan Siddique <nusididq@redhat.com>
* ofproto: Move may_enable from ofport_dpif to ofport.Ben Pfaff2018-10-181-0/+1
| | | | | | | | | | | This concept of whether a port is suitable to be "live" in the sense of the OpenFlow OFPPS_LIVE bit is a generic one that can be handled at the ofproto layer instead of needing to be part of ofproto-dpif. An upcoming commit will make more use of this at the ofproto layer. Signed-off-by: Ben Pfaff <blp@ovn.org> Acked-by: Numan Siddique <nusididq@redhat.com>
* ofproto: Refactor update_port().Ben Pfaff2018-10-181-25/+9
| | | | | | | | | update_port() worked a little too hard to avoid copying and comparing some bits in the ofputil_phy_port. This seems like a simpler approach all around. It should behave the same way. Signed-off-by: Ben Pfaff <blp@ovn.org> Acked-by: Numan Siddique <nusididq@redhat.com>
* connmgr: Suppress duplicate port status notifications.Ben Pfaff2018-10-181-8/+10
| | | | | | | | | | | | | When the status of a port changes, ofproto calls into connmgr to notify controllers. Sometimes, particular changes are only visible to controllers running specific versions of OpenFlow. Until now, OVS would send those controllers duplicate port status notifications. This is unnecessary and somewhat confusing. This commit eliminates it. This commit updates one of the tests not to expect duplicate notifications. Signed-off-by: Ben Pfaff <blp@ovn.org> Acked-by: Numan Siddique <nusididq@redhat.com>
* ofproto: Fix build with some GCC versions.Ben Pfaff2018-09-271-7/+6
| | | | | | | | | | GCC 4.8.x and possibly other versions don't like a designated initializer for an anonymous struct, see e.g. https://travis-ci.org/openvswitch/ovs/jobs/433747674 Fixes: f836888d28ec ("ofproto: Handle OpenFlow version mismatch for requestforward with groups.") Signed-off-by: Ben Pfaff <blp@ovn.org> Acked-by: Justin Pettit <jpettit@ovn.org>
* ofproto: Handle OpenFlow version mismatch for requestforward with groups.Ben Pfaff2018-09-261-4/+7
| | | | | | | | | | | | | | | OpenFlow 1.4+ supports a feature called requestforward. When a controller enables this feature, the switch sends that controller a copy of other controllers' group and meter modification requests. OpenFlow 1.5 supports some group features not in OpenFlow 1.4. When OVS attempted to forward such requests to an OpenFlow 1.4 controller, it reported an error and exited. This commit fixes the problem by making OVS properly translate the messages to OpenFlow 1.4 format. Reported-by: Pierre Cregut <pierre.cregut@orange.com> Tested-by: Pierre Cregut <pierre.cregut@orange.com> Reported-at: https://mail.openvswitch.org/pipermail/ovs-discuss/2018-September/047453.html Signed-off-by: Ben Pfaff <blp@ovn.org>
* ofproto: Fix coredump in ofproto_destroy__().liucheng (J)2018-08-151-0/+2
| | | | | | | | | | | | | | | | | | | | | | | There is a coredump when I add and delete bridges. When the rcu thread call ofproto_destroy__, the main thread may call ofproto_create. But the ofproto_destroy__ fun doesn't have the ofproto_mutex when access the all_ofprotos. #0 0x00007f824aa0d197 in raise () from /usr/lib64/libc.so.6 #1 0x00007f824aa0e888 in abort () from /usr/lib64/libc.so.6 #2 0x0000000000658249 in PAT_abort () #3 0x000000000065538d in patchIllInsHandler () #4 <signal handler called> #5 0x0000000000478a5b in hmap_remove (node=0x3320150, hmap=0x95fc40 <all_ofprotos>) at include/openvswitch/hmap.h:287 #6 ofproto_destroy__ (ofproto=0x3320150) at ofproto/ofproto.c:1642 #7 0x0000000000535e46 in ovsrcu_call_postponed () at lib/ovs_rcu.c:323 #8 0x0000000000536014 in ovsrcu_postpone_thread (arg=<optimized out>) at lib/ovs_rcu.c:338 #9 0x0000000000538488 in ovsthread_wrapper (aux_=<optimized out>) at lib/ovs_thread.c:682 #10 0x00007f824c130dc5 in start_thread () from /usr/lib64/libpthread.so.0 #11 0x00007f824aacf7bd in clone () from /usr/lib64/libc.so.6 Signed-off-by: Cheng Liu <liucheng11@huawei.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* ofp-actions: Split ofpacts_check__() into many functions.Ben Pfaff2018-07-311-4/+8
| | | | | | | | | | | ofpacts_check__() was a huge switch statement with special cases for many different kinds of actions. This made it unwieldy and put the special cases far away from the rest of the code related to a given action. This commit refactors the code to avoid the problem. Signed-off-by: Ben Pfaff <blp@ovn.org> Tested-by: Yifeng Sun <pkusunyifeng@gmail.com> Reviewed-by: Yifeng Sun <pkusunyifeng@gmail.com>
* ofproto: Add support for specifying a meter in controller actions.Justin Pettit2018-07-301-0/+44
| | | | | Signed-off-by: Justin Pettit <jpettit@ovn.org> Acked-by: Ben Pfaff <blp@ovn.org>
View Lorry Controller Status