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
