[ovs-dev] [ovs-dev,v9,05/10] Persist local_datapaths

Ryan Moats rmoats at us.ibm.com
Wed Mar 23 17:22:00 UTC 2016


Ben Pfaff <blp at ovn.org> wrote on 03/23/2016 11:23:38 AM:

> From: Ben Pfaff <blp at ovn.org>
> To: Ryan Moats/Omaha/IBM at IBMUS
> Cc: dev at openvswitch.org
> Date: 03/23/2016 11:23 AM
> Subject: Re: [ovs-dev,v9,05/10] Persist local_datapaths
>
> On Wed, Mar 23, 2016 at 07:46:57AM -0600, Ryan Moats wrote:
> > Ben Pfaff <blp at ovn.org> wrote on 03/22/2016 05:05:22 PM:
> > > 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?
> >
> > 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...
>
> I thought that the change-tracking code retained deleted rows for
> inspection until the tracking cache was flushed.  If it doesn't, then
> maybe that should be changed.

It doesn't (and I'm not sure it should because of the issues I've seen
with trying to flush the tracing cache - I'm still not doing it in any of
this code)

> At the very least, I would think that the uuid of the deleted row would
> be available.

Yes, I've verified that is available, and so I've happily dumped all of
the sequence number magic for using row uuids - I still have to generate
one for the four flows that aren't associated with any database row, but
I've already added comments to that effect in the patch sets I'm working
on.



More information about the dev mailing list