lflow_run() is the main logical flows processing routine that we spend
most of the CPU time in when testing at scale.

With the switch to incremental processing approach in the controller,
we will be trying to avoid calling to lflow_run() as much as possible.

A counter lets us confirm that we are doing logical flow processing
only when it's expected, without resorting to profiling under stress.

It can also serve as a hint as to why ovn-controller process is
consuming CPU time.

Signed-off-by: Jakub Sitnicki <j...@redhat.com>
---
 ovn/controller/lflow.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/ovn/controller/lflow.c b/ovn/controller/lflow.c
index d75e03ffb..171ee102d 100644
--- a/ovn/controller/lflow.c
+++ b/ovn/controller/lflow.c
@@ -14,6 +14,7 @@
  */
 
 #include <config.h>
+#include "coverage.h"
 #include "gchassis.h"
 #include "lflow.h"
 #include "lport.h"
@@ -34,6 +35,8 @@
 #include "sset.h"
 
 VLOG_DEFINE_THIS_MODULE(lflow);
+
+COVERAGE_DEFINE(lflow_run);
 
 /* Symbol table. */
 
@@ -553,6 +556,8 @@ lflow_run(struct ovn_desired_flow_table *flow_table,
           struct sset *local_lport_ids,
           uint32_t *conj_id_ofs)
 {
+    COVERAGE_INC(lflow_run);
+
     add_logical_flows(flow_table, ctx, chassis_index, local_datapaths,
                       group_table, meter_table, chassis, addr_sets,
                       port_groups, active_tunnels, local_lport_ids,
-- 
2.14.3

_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to