Building on some of the suggestions in this thread, a patch/pull-request was submitted to add support for change tracking in ovsdb-idl:
https://github.com/openvswitch/ovs/pull/78 Another ovsdb-idl scaling use case of interest is update notifications for columns that change frequently. Classic case is columns that represent counters. If an ovsdb client is interested in fetching a value of a specific column of a specific row, it needs to turn on monitoring for that column. For a column representing a frequently changing value this would entail frequent update notification from the ovsdb server. Does it make send to implement ovsdb-idl api's to allow a client to fetch a column value on-demand, without having to monitor (replicate) that column? Any thoughts on this? > -----Original Message----- > From: Ben Pfaff [mailto:b...@nicira.com] > Sent: Monday, August 03, 2015 9:08 PM > To: Ansari, Shad > Cc: Saurabh Shrivastava (सौरभ श्रीवास्तव); discuss@openvswitch.org > Subject: Re: [ovs-discuss] Scaling ovsdb-idl's update notification > > If that's useful for real applications, and more practical, then I'm all > for it. I haven't thought about the problem carefully; I'm just trying > to point out a constraint. > > On Mon, Aug 03, 2015 at 07:10:23PM +0000, Ansari, Shad wrote: > > Would it help if, for the deleted record, all fields except uuid, > > version, and indexes columns are reset to default (after regular > > deferred processing - unreferenced rows are deleted and dangling weak > > references are removed)? This ensures that the client does not access > > invalid references. Typically, the uuid or indexes should be > > sufficient information for the client to take action. > > > > > > -----Original Message----- > > From: Ben Pfaff [mailto:b...@nicira.com] > > Sent: Monday, August 03, 2015 9:51 AM > > To: Saurabh Shrivastava (सौरभ श्रीवास्तव) > > Cc: Ansari, Shad; discuss@openvswitch.org > > Subject: Re: [ovs-discuss] Scaling ovsdb-idl's update notification > > > > 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 <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
