[ovs-dev] [RFC] ovn-northd: Store computed logical flow hash in SBDB.
Jakub Sitnicki
jkbs at redhat.com
Thu Feb 15 10:18:24 UTC 2018
On Wed, 14 Feb 2018 13:58:16 -0800
Ben Pfaff <blp at ovn.org> 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
More information about the dev
mailing list