Ben Pfaff <b...@ovn.org> wrote on 02/05/2016 04:20:04 PM: > From: Ben Pfaff <b...@ovn.org> > To: Ryan Moats/Omaha/IBM@IBMUS > Cc: dev@openvswitch.org > Date: 02/05/2016 04:20 PM > Subject: Re: [ovs-dev] [PATCH] [ovn-controller] [RFC] Poor man's > lflow incremental processing > > On Fri, Feb 05, 2016 at 03:41:24PM -0600, Ryan Moats wrote: > > Ben Pfaff <b...@ovn.org> wrote on 02/05/2016 01:01:56 PM: > > > > > From: Ben Pfaff <b...@ovn.org> > > > To: Ryan Moats/Omaha/IBM@IBMUS > > > Cc: dev@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 <rmo...@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. >
I'll definitely revisit that as that was *not* the intent... Ryan _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
