<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 29, 2019 at 12:16 PM Numan Siddique &lt;<a href="mailto:nusiddiq@redhat.com">nusiddiq@redhat.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 30, 2019 at 12:37 AM Han Zhou &lt;<a href="mailto:zhouhan@gmail.com" target="_blank">zhouhan@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><br>On Thu, Aug 29, 2019 at 11:40 AM Numan Siddique &lt;<a href="mailto:nusiddiq@redhat.com" target="_blank">nusiddiq@redhat.com</a>&gt; wrote:<br>&gt;<br>&gt; Hello Everyone,<br>&gt;<br>&gt; In one of the OVN deployments, we are seeing 100% CPU usage by ovn-controllers all the time.<br>&gt;<br>&gt; After investigations we found the below<br>&gt;<br>&gt;  - ovn-controller is taking more than 20 seconds to complete full loop (mainly in lflow_run() function)<br>&gt;<br>&gt;  - The physical switch is sending GARPs periodically every 10 seconds.<br>&gt;<br>&gt;  - There is ovn-bridge-mappings configured and these GARP packets reaches br-int via the patch port.<br>&gt;<br>&gt;  - We have a flow in router pipeline which applies the action - put_arp <br>&gt; if it is arp packet.<br>&gt;<br>&gt;  - 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.<br>&gt;<br>&gt;  - 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.<br>&gt;<br>&gt; - This causes the ovn-controller poll_block() to not sleep at all and this repeats all the time resulting in 100% cpu usage.<br>&gt;<br>&gt; The deployment has OVS/OVN 2.9.  We have back ported the pinctrl_thread patch.<br>&gt;<br>&gt; 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" target="_blank">https://mail.openvswitch.org/pipermail/ovs-dev/2019-July/360414.html</a><br>&gt;<br>&gt; I think we need to improve the logical processing sooner or later.<br>&gt;<br>&gt; But to fix this issue urgently, we are thinking of the below approach.<br>&gt;<br>&gt;  - 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).<br>&gt;<br>&gt; - 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.<br>&gt;<br>&gt; 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. <br>&gt;<br>&gt; In the present master/2.12 these GARPs will not cause this 100% cpu loop issue because incremental processing will not recompute flows.<br>&gt;<br>&gt; 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.<br>&gt;<br>&gt; I would like to know your comments and any concerns if any.<br>&gt;<br>&gt; Thanks<br>&gt; Numan<br><div>&gt;</div><div><br></div><div>Hi Numan,</div><div><br></div><div>I think this approach should work. Just to make sure, to update the cache efficiently (to avoid another kind of recompute), it should use ovsdb change-tracking to update it incrementally.</div><br><div>Regarding master/2.12, it is not harmful except that it will add some more code and increase memory footprint. For our current use cases, there can be easily 10,000s mac_bindings, but it may still be ok because each entry is very small. However, is there any benefit for doing this in master/2.12?<br></div></div></blockquote><div><br></div><div>I don&#39;t see much benefit. But I can&#39;t submit a patch to branch 2.9 without the fix getting merged in master first right ?</div><div>May be once it is merged in branch 2.9, we can consider to delete it ?</div><div><br></div></div></div></blockquote><div>I think it is just about how would you maintain a downstream branch. Since it is downstream, I don&#39;t think you need a change to be in upstream before fixing a problem. In this case it may be *no harm*, but what if the upstream is completely changed and incompatible for such a fix any more? It shouldn&#39;t prevent you from fixing your downstream. (Of course it is better to not have downstream at all, but sometimes it is useful to have it for a temporary period, and since you (and us, too) are already there ... :)<br></div></div></div>