| Message ID | 20180518165537.32002-2-jkbs@redhat.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | ovn: Observe and check for effects of incremental processing | expand |
On Fri, May 18, 2018 at 9:55 AM, Jakub Sitnicki <jkbs@redhat.com> wrote: > > 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 <jkbs@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 > Jakub, thanks for adding the statistics for incremental processing! Acked-by: Han Zhou <hzhou8@ebay.com>
On Fri, May 18, 2018 at 06:55:35PM +0200, Jakub Sitnicki wrote: > 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 <jkbs@redhat.com> This one seemed obviously correct so I applied it to master even though it's an RFC.
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,
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 <jkbs@redhat.com> --- ovn/controller/lflow.c | 5 +++++ 1 file changed, 5 insertions(+)