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)
_______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
