<div dir="ltr">Hello Everyone,<div><br></div><div>In one of the OVN deployments, we are seeing 100% CPU usage by ovn-controllers all the time.</div><div><br></div><div>After investigations we found the below</div><div><br></div><div> - ovn-controller is taking more than 20 seconds to complete full loop (mainly in lflow_run() function)</div><div><br></div><div> - The physical switch is sending GARPs periodically every 10 seconds.</div><div><br></div><div> - There is ovn-bridge-mappings configured and these GARP packets reaches br-int via the patch port.</div><div><br></div><div> - We have a flow in router pipeline which applies the action - put_arp </div><div>if it is arp packet.</div><div><br></div><div> - ovn-controller pinctrl thread receives these garps, stores the learnt mac-ips in the &#39;put_mac_bindings&#39; hmap and notifies the ovn-controller main thread by incrementing the seq no.</div><div><br></div><div> - In the ovn-controller main thread, after lflow_run() finishes, pinctrl_wait() is called. This function calls - poll_immediate_wake() as &#39;put_mac_bindings&#39; hmap is not empty.</div><div><br></div><div>- This causes the ovn-controller poll_block() to not sleep at all and this repeats all the time resulting in 100% cpu usage.</div><div><br></div><div>The deployment has OVS/OVN 2.9.  We have back ported the pinctrl_thread patch.</div><div><br></div><div>Some time back I had reported an issue about lflow_run() taking lot of time - <a href="https://mail.openvswitch.org/pipermail/ovs-dev/2019-July/360414.html">https://mail.openvswitch.org/pipermail/ovs-dev/2019-July/360414.html</a></div><div><br></div><div>I think we need to improve the logical processing sooner or later.</div><div><br></div><div>But to fix this issue urgently, we are thinking of the below approach.</div><div><br></div><div> - pinctrl_thread will locally cache the mac_binding entries (just like it caches the dns entries). (Please note pinctrl_thread can not access the SB DB IDL).</div><div><br></div><div>- Upon receiving any arp packet (via the put_arp action), pinctrl_thread will check the local mac_binding cache and will only wake up the main ovn-controller thread only if the mac_binding update is required.</div><div><br></div><div>This approach will solve the issue since the MAC sent by the physical switches will not change. So there is no need to wake up ovn-controller main thread. </div><div><br></div><div>In the present master/2.12 these GARPs will not cause this 100% cpu loop issue because incremental processing will not recompute flows.</div><div><br></div><div>Even though the above approach is not really required for master/2.12, I think it is still Ok to have this as there is no harm.</div><div><br></div><div>I would like to know your comments and any concerns if any.</div><div><br></div><div>Thanks</div><div>Numan</div><div><br></div></div>