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? Thanks, Ben. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev