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

Saurabh Shrivastava (सौरभ श्रीवास्तव) saurabh at gmail.com
Sun Aug 2 20:08:56 UTC 2015


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20150802/67ab3849/attachment-0002.html>


More information about the discuss mailing list