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
