[ovs-dev] [ovs-dev,v9,05/10] Persist local_datapaths
Ryan Moats
rmoats at us.ibm.com
Wed Mar 23 13:46:57 UTC 2016
Ben Pfaff <blp at ovn.org> wrote on 03/22/2016 05:05:22 PM:
> From: Ben Pfaff <blp at ovn.org>
> To: Ryan Moats/Omaha/IBM at IBMUS
> Cc: dev at openvswitch.org
> Date: 03/22/2016 05:05 PM
> Subject: Re: [ovs-dev,v9,05/10] Persist local_datapaths
>
> On Fri, Mar 11, 2016 at 03:06:20PM -0600, Ryan Moats wrote:
> > From: RYAN D. MOATS <rmoats at us.ibm.com>
> >
> > Persist local_datapaths across runs so that a change can be used
> > as a trigger to reset incremental flow processing.
> >
> > Signed-off-by: RYAN D. MOATS <rmoats at us.ibm.com>
>
> One thing I'm trying to understand in this series is the reliance on
> seqnos that come from the IDL. I'm surprised that they're used so
> much. I would have guessed that the typical use of change tracking
> would be something like this:
>
> For each row that changed,
> If it's new, create a new object to track it;
> otherwise, it's modified or deleted, so look up an existing
> object based on the row's uuid and update or delete it as
> appropriate
>
> But instead logic seems to look at these seqnos a lot. What is the
> principle that you're following?
>
> In this patch, I suspect that 'local_datapaths' should be static.
>
I chose to use IDLs instead of the row's uuid because the insert seqno
acts as pretty much as a uuid and I was sure that I could trust them
even when a row is deleted. Unfortunately, that led to a bunch of
"magic" that I really didn't like. I'll go back and double check to
make sure that a row uuid's remain usable after a row is deleted - if
they do, then I'm all in favor of using uuids as it should simplify
a bunch of things...
Ryan (regXboi)
More information about the dev
mailing list