Thanks for working on making OVN faster and scale better.
I see what you mean about how nb_cfg can be a scale problem. Really,
each hypervisor only cares about its own row, but each of them is being
notified about the current value in every row. Ideally, we want the HVs
to be able to say to ovsdb-server, "Give me all the data in the Chassis
table, except don't bother with nb_cfg in any rows except my own row."
Actually, there's a way for ovn-controller to do that: the OVSDB
protocol definition of monitor_cond allows the client to specify
multiple sets of columns to monitor in a table, and each set of columns
has an independently attached condition. This can be used to specify
that most of the columns are monitored unconditionally but nb_cfg is
monitored only for a particular row.
But there are still problems:
1. The implementation in ovsdb-server looks broken. I don't think it
implements the spec. It certainly isn't tested--none of the existing
clients ever passes more than a single set of columns. I think that
it will work if all the sets of columns use the same condition, but
that doesn't help with this case. It will need to be fixed.
2. The client implementation in ovsdb-idl doesn't anticipate difference
conditions for different columns. It will need to be enhanced to
support this use.
In the short term this is going to be more work than just creating a new
table. In the long term, though, it will allow us to be more flexible
and more agile, since improvements similar to the one in this patch will
require only client changes, not database schema changes.
dev mailing list