On Wed, 14 Feb 2018 13:58:16 -0800 Ben Pfaff <[email protected]> wrote: > On Tue, Feb 13, 2018 at 02:57:40PM +0100, Jakub Sitnicki wrote: > > Each time ovn-northd processes the NBDB contents it has to compute the > > hash of every logical flow stored in the SBDB in order to identify ones > > that need adding to or deleting from SBDB (build_lflows()). > > > > Avoid it by storing the logical flow hash together with its fields the > > moment we first add it to SBDB. This saves us the hash computations > > afterwards, every time ovn-northd processes the logical flows to find > > candidates for removal/addition. > > > > In a simple micro-benchmark that adds 15 logical switches with 100 > > logical ports each, perf tool shows a drop of 7% in CPU cycles > > ('cycles:ppp' event) spent in ovn_lflow_find() where we compute the hash > > of each logical flow found in SBDB: > > > > Children Self Command Shared Object Symbol > > before: 10.61% 0.17% ovn-northd ovn-northd [.] > > ovn_lflow_find > > after: 2.82% 0.19% ovn-northd ovn-northd [.] > > ovn_lflow_find > > This is good work, thanks for figuring this out. > > I think that it is better if this kind of thing is not actually stored > in the database. It adds a risk that the hash could get out of sync > with the rest of a row, and there is no guarantee that the hash function > is the same from one version of OVS to the next or between little and > big endian architectures on the same version of OVS. > > However, we can still do better by calculating the hash only a single > time on the client and only recalculating it if the row otherwise > changes. I had a branch a while back that implemented something more > ambitious than this, so I cut it down and polished it up and this is > what I came up with: > https://patchwork.ozlabs.org/project/openvswitch/list/?series=28651 > > Would you mind testing it to see whether its performance benefit is > similar to what you observed?
Ben, I agree, storing the hash in the database can be a source of problems. Your synthetic column solution is much cleaner. I will profile it and report back. Thanks, Jakub _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
