"dev" <dev-boun...@openvswitch.org> wrote on 02/05/2016 05:09:44 PM:
> From: Ryan Moats/Omaha/IBM@IBMUS > To: Ben Pfaff <b...@ovn.org> > Cc: dev@openvswitch.org > Date: 02/05/2016 05:10 PM > Subject: Re: [ovs-dev] [PATCH] [ovn-controller] [RFC] Poor man's > lflow incremental processing > Sent by: "dev" <dev-boun...@openvswitch.org> > > 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 Yes, that is a definite mistake and the more I look at this, the more I think it just isn't going to work correctly the way I've tried to code it. Trying to mark logical flows as dirty either means changing how the IDL code is generated (which doesn't strike me as a good idea) or adding a "dirty" column to the Logical_Flows table, which then means I'm looking at modifying the ovsdb_idl_txn_write__ code to touch this column appropriately and then adding code into lflow_run() method to clear this column (which can be done, but still feels a little crufty). Ben, does this analysis look right to you or am I missing a third path? Ryan _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
