[ovs-dev] [PATCH ovn v5] Avoid nb_cfg update notification flooding

[Dumitru Ceara]

On 8/8/20 8:35 AM, Han Zhou wrote:
> nb_cfg as a mechanism to "ping" OVN control plane is very useful
> in many ways. However, the current implementation will trigger
> update notifications flooding in the whole control plane. Each
> HV updates to SB the nb_cfg number and all these updates are
> notified to all the other HVs, which is O(n^2). Although updates
> are batched in fewers notifications than n^2, it still generates
> significant load on SB DB and ovn-controllers.
> 
> To solve this problem and make the mechanism more useful in large
> scale producation deployment, this patch separates the per HV
> *private* data (write only by the owning chassis and not
> interesting to any other HVs) from the Chassis table to a separate
> table, so that each HV can conditionally monitor and get updates
> only for its own record.
> 
> Test result shows great improvement:
> In a test environment with 1200 sandbox HVs, and 12K ports created
> on 80 lswitches and 1 lrouter, do the sync test when the system
> is idle, with command:
> 
>     time ovn-nbctl --wait=hv sync
> 
> Original result:
> real    0m13.724s
> user    0m0.295s
> sys     0m0.012s
> 
> With this patch:
> real    0m3.255s
> user    0m0.248s
> sys     0m0.020s
> 
> Also, regarding backwards compatibility note that the nb_cfg from the
> Chassis table is no longer updated. If any system is relying on this
> mechanism they should start using the nb_cfg from the Chassis_Private
> table from now on.
> 
> Co-authored-by: Lucas Alvares Gomes <lucasagomes at gmail.com>
> Signed-off-by: Lucas Alvares Gomes <lucasagomes at gmail.com>
> Signed-off-by: Han Zhou <hzhou at ovn.org>
> ---

Looks good to me, thanks!

Acked-by: Dumitru Ceara <dceara at redhat.com>