[ovs-dev] [PATCH] [ovn-controller] [RFC] Poor man's lflow incremental processing

[Ben Pfaff]

On Fri, Feb 05, 2016 at 03:41:24PM -0600, Ryan Moats wrote:
> Ben Pfaff <blp at ovn.org> wrote on 02/05/2016 01:01:56 PM:
> 
> > From: Ben Pfaff <blp at ovn.org>
> > To: Ryan Moats/Omaha/IBM at IBMUS
> > Cc: dev at openvswitch.org
> > Date: 02/05/2016 01:02 PM
> > Subject: Re: [ovs-dev] [PATCH] [ovn-controller] [RFC] Poor man's
> > lflow incremental processing
> >
> > On Wed, Feb 03, 2016 at 04:20:23PM -0600, RYAN D. MOATS wrote:
> > > Add incremental processing of lflows in ovn-controller by
> > > taking the simple approach of marking each lflow dirty when
> > > touched and have lflow_run only process dirty flows.
> > >
> > > This needs unit test code before the RFC tag comes off.
> > >
> > > Signed-off-by: RYAN D. MOATS <rmoats at us.ibm.com>
> >
> > I was envisioning something that would incrementally determine on a
> > per-flow basis whether anything needed to be recalculated.  Starting
> > with a per-logical-datapath approach, as this patch does, is a nice
> > place to start because it is presumably easier, so I think it's a good
> > idea.
> 
> I suspect we'll get to that point eventually, but I figured this would be
> easier to start with...
> 
> > I don't understand how this particular patch is going to make a
> > difference, though, since ldp_run() appears to always dirty every
> > logical datapath.
> 
> Well, when I ran the test that I used on Russell's now merged patch that
> improved things 15%, I was still seeing that each lflow_run call would
> process
> 36020 logical datapaths, 40012 matches and take a little more than half a
> second to complete
> 
> Running that same test on this patch resulted in (after completion)
> only 2797 of the 36020 logical datapaths being processed - these generated
> 2934 matches being reprogrammed and a lflow_run call would complete in less
> than 50 msec.

I think this is because lflow_run() marks a logical datapath "clean"
after processing any one logical flow in the datapath.  I don't know why
it does that, but on the face of it it seems wrong.