[cc + Dave and Terry] On Thu, Aug 12, 2021 at 2:19 PM Han Zhou <[email protected]> wrote:
> > > On Tue, Aug 10, 2021 at 9:32 AM Flavio Fernandes <[email protected]> > wrote: > > > > [cc: Ben + Dmitry] > > > > Hi folks, > > > > I'm looking at some conversion code in ovn-org/ovn-kubernetes where we > replace the ovn-nbctl wrapper with the libovsdb library ( ovn-org/libovsdb > ). Since we are mostly doing this to make it faster (besides reducing the > memory footprint), using the "Where" syntax [1] will greatly benefit > operations on logical-router [2] and logical-switch [3] tables if they were > indexed by name. Similar to what we already have for the logical-router > port and logical-switch port tables. > > > > After listening to episode 72 of OVS Orbit [4], I would like to ask: > does anyone have objections to adding "indexes": [["name"]], to the > logical-router [2] and logical-switch [3] tables? I understand Ben's point > on making the implementation of the locally-cached tables have these types > of optimizations, but at the same time, I see these 2 tables as low-hanging > fruits when scaling deployments with lots of lr's and ls's. Unless there is > an implementation that use nameless rows for these tables, I cannot think > of a usage case where duplicate names are useful. Do you? > > > > Depending on your answers, I can propose a tweak to the schema to have > these changes... or not. ;) > > > > Thanks, > > > > -- flaviof > > > > [1]: https://github.com/ovn-org/libovsdb/pull/209 > > [2]: > https://github.com/ovn-org/ovn/blob/d08f89e219e1fa45583757bd2804783cf0630179/ovn-nb.ovsschema#L306 > > [3]: > https://github.com/ovn-org/ovn/blob/d08f89e219e1fa45583757bd2804783cf0630179/ovn-nb.ovsschema#L41 > > [4]: https://ovsorbit.org/ ==> Episode 72: The OVSDB Query Optimizer > and Key-Value Interface, with Dmitry Yusupov from NVIDIA (Feb 27, 2021) > > _______________________________________________ > > discuss mailing list > > [email protected] > > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > > I have no objection to the schema change, as long as it is declared as > incompatible change in the NEWS and add some guide in the upgrading topics > in the documentation regarding how to solve the problem when upgrading. > > However I don't see a link between this and [4]. The talk was about server > side indexes which optimizes “select“ operations while what libovsdb does > is on the local cache. The pr [1] seems could utilize the index in the > schema but is not related to the server side indexes. > > In addition I would propose that libovsdb add support for adding > customized indexes with some new APIs (of course not tied to any schema), > not only on primary keys but other columns as needed by clients, and then > schema wouldn’t matter that much for the cache indexes. > You are absolutely right, Ben & Han! The only 'connection' between this and [4] is that libovsdb is smart in indexing rows in its local cache based on the schema. Not a good enough reason to break backwards compatibility. @Dave: please correct me if I'm talking nonsense here. :) So, after thinking some more about this, I agree that making libovsdb capable of indexing additional columns not mentioned in the schema is indeed a much better approach. I also asked Terry and looked at what we currently do in ml2/ovn, via ovsdbapp [5] [6]. Since LS and LR in ovn-k8 use unique names (same as in Neutron), that enhancement may not even have to deal with duplicates. Thank you so much for your (and blp's) feedback on this !!! -- flaviof [5]: https://review.opendev.org/#/c/678076/ [6]: https://github.com/openstack/ovsdbapp/blob/35c8eae020ef5300e08b7869e5da11dd0e2c500e/ovsdbapp/schema/ovn_northbound/impl_idl.py#L24-L26 > > Thanks, > Han >
_______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
