[ovs-discuss] Scaling ovsdb-idl's update notification

Ben Pfaff blp at nicira.com
Mon Aug 3 16:50:39 UTC 2015


That kind of approach might work.

It's important to keep in mind, though, that the IDL isn't just a
collection of unrelated records.  It's a graph: any record can point to
any number of other records, through columns whose types are UUIDs with
refTable constraints.  The IDL maintains tracks these relationships
carefully for memory safety, so that if a record is deleted then the
pointers to it from other records can be dropped.  Any approach to
handling changes may have to take this into account.

On Sun, Aug 02, 2015 at 01:08:56PM -0700, Saurabh Shrivastava (सौरभ श्रीवास्तव) wrote:
> One approach can be to link all the struct ovsdb_idl_row in a linked list
> where nodes are ordered by their time of update ie a newly added node is
> put at the end of the linked list, an updated node is removed from its
> current position and put at the end of the linked list, a deleted node is
> kept in the linked list till it is notified to the idl user. The size of
> this linked list will be the number of rows in the table. A new ovsdb-idl
> API can be called to iterate over this linked list one at a time, the API
> can place a marker node in the linked list to remember till what point the
> notifications have been generated. The IDL user should not try to
> dereference the pointers in  a "delete" event because the pointers could be
> stale, so it should only look at the embedded UUID.
> 
> The benefit of this approach is that IDL user gets notified only of the
> changes, and also updates get naturally dampened ie large number of
> modifications to a single row gets delivered as fewer number of events.
> 
> 
> --
> Saurabh (सौरभ)
> 
> On Sun, Aug 2, 2015 at 12:06 PM, Ben Pfaff <blp at nicira.com> wrote:
> 
> > On Fri, Jul 31, 2015 at 08:03:41PM +0000, Ansari, Shad wrote:
> > >
> > > Ovsdb-idl notifies a client that "something" changed; it does not track
> > "what" changed. The client then typically either reconfigures itself by
> > scanning the idl to determine what changed, or - simply reloads the entire
> > idl. This presumably works since the ovs schema tables aren't typically
> > large.
> > >
> > > In a use-case where ovsdb is used with a schema that can have very large
> > tables (imagine route table), the current ovsdb-idl notification mechanism
> > doesn't appear to scale - clients need to do a lot of processing to
> > determine the exact change delta.
> > >
> > > I would like to hear from others if they have any views/insights on how
> > to handle this scalability use-case. Obviously, this will require changes
> > in ovsdb-idl, possibly on the lines of:
> > >
> > > -        Supporting more granular sequence numbers (table, row, column)
> > >
> > > -        Giving client visibility to the update (so that the client can
> > view both the old, new data)
> >
> > I'm welcome to discussion and proposals in this area.  I've expected for
> > years that we'd eventually need something like this for ovs-vswitchd
> > (although so far it isn't a big deal), and the same could be true for
> > ovn-controller as OVN begins to scale.
> > _______________________________________________
> > discuss mailing list
> > discuss at openvswitch.org
> > http://openvswitch.org/mailman/listinfo/discuss
> >



More information about the discuss mailing list