[ovs-dev] [RFC] ovn-northd: Store computed logical flow hash in SBDB.

[Ben Pfaff]

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.