[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