On 8/10/23 18:56, Dumitru Ceara wrote: > On 8/10/23 18:15, Han Zhou wrote: >> Thanks Vladislav and Dumitru for reporting and fixing the issue. >> The impact of the issue is more than just the memory spikes in >> ovn-controller. More importantly, it incurs much higher load on SB DB >> because the conditions are flooded with all the localnet ports regardless >> of whether they belong to local datapaths. >> Please see more details in a related fix I just posted: >> https://patchwork.ozlabs.org/project/ovn/patch/20230810155351.2853369-1-hz...@ovn.org/ >> >> In addition, I want to comment on Dumitru's patch (sorry I still didn't see >> you posted for review yet) >> https://github.com/dceara/ovn/commit/f5e8b9bcba61a2528b67854bb4211981a99feaa8, >> I think it is better to avoid using the "optional" version for port_binding >> monitoring. For the same reason, if my patch above is not applied, the SB >> DB overload problem is still there because the unconditional monitoring of >> port_binding initially adds all localnet ports to local_lports and later to >> the monitor conditions. In addition, if there are a huge amount of PBs, it >> may still cause memory pressure. I understand the intention of avoiding >> churns of building local_datapaths, but it may be better to be addressed in >> a separate patch and we can review and discuss accordingly. >> > > The unfortunate part is the fact that the local datapath "churn" will > also cause conntrack zones to be flushed and disrupt traffic. What's > worse (in the ovn-k8s case) is that some of the zones (zone 0) might be > shared with the host. So, just restarting ovn-controller (with > conditional monitoring enabled) will trigger conntrack entries to be > cleared for non-OVN sessions too. > >
I think I found a reasonable way forward. I posted a formal series: https://patchwork.ozlabs.org/project/ovn/list/?series=368430&state=* Regards, Dumitru _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
