[ovs-dev] [ovs-dev, v17, 5/5] Add incremental proessing to lflow_run and physical_run

Ben Pfaff blp at ovn.org
Tue Jun 7 04:18:56 UTC 2016


On Mon, Jun 06, 2016 at 02:04:37PM -0500, Ryan Moats wrote:
> Ben Pfaff <blp at ovn.org> wrote on 06/06/2016 10:51:57 AM:
> 
> > From: Ben Pfaff <blp at ovn.org>
> > To: Ryan Moats/Omaha/IBM at IBMUS
> > Cc: dev at openvswitch.org
> > Date: 06/06/2016 10:52 AM
> > Subject: Re: [ovs-dev, v17, 5/5] Add incremental proessing to
> > lflow_run and physical_run
> >
> > On Mon, Jun 06, 2016 at 10:26:46AM -0500, Ryan Moats wrote:
> > >
> > >
> > > Ben Pfaff <blp at ovn.org> wrote on 06/03/2016 10:55:53 AM:
> > >
> > > > From: Ben Pfaff <blp at ovn.org>
> > > > To: Ryan Moats/Omaha/IBM at IBMUS
> > > > Cc: dev at openvswitch.org
> > > > Date: 06/03/2016 10:56 AM
> > > > Subject: Re: [ovs-dev, v17, 5/5] Add incremental proessing to
> > > > lflow_run and physical_run
> > > >
> > > > On Sun, May 22, 2016 at 04:36:22PM -0500, Ryan Moats wrote:
> > > > > This code changes to allow incremental processing of the
> > > > > logical flow and physical binding tables whenver possible.
> > > > >
> > > > > Side Effects:
> > > > >   - Make flow table persistent in ovn controller
> > > > >   - Reset lflow processing when adding/removing patch ports
> > > > >
> > > > > Note: flows created by physical_run for multicast_groups are
> > > > > *NOT* handled incrementally due to to be solved issues
> > > > > with GWs and local routers.
> > > > >
> > > > > Signed-off-by: Ryan Moats <rmoats at us.ibm.com>
> > > >
> > > > This seems quite reasonable.
> > > >
> > > > The changes to physical.c are large.  Are they mostly moving code
> > > > around?
> > >
> > > Unfortunately, yes they are - I'm wondering if I'm better off
> > > doing a couple of "refactoring" patches in the series where I extract
> > > the code that will be used in both the FOR_EACH and FOR_EACH blocks
> > > (I'm open to suggestions)...
> >
> > I'm OK with moving code around, but please add something to the commit
> > message mentioning that's what happening.  It makes the commit easier to
> > review because I'm not spending time trying to compare blocks of code
> > that are actually the same.
> 
> I think I'm going to help you out by breaking the "move blocks of
> code around" actions into separate commits. This last patch set isn't
> wanting to rebase and it's large enough that trying to find the *why*
> is becoming difficult.

Even better!



More information about the dev mailing list