[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