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 <b...@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@openvswitch.org > http://openvswitch.org/mailman/listinfo/discuss >
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
