<div dir="ltr"><br><br>On Fri, Aug 30, 2019 at 6:46 AM Mark Michelson &lt;<a href="mailto:mmichels@redhat.com">mmichels@redhat.com</a>&gt; wrote:<br>&gt;<br>&gt; On 8/30/19 5:39 AM, Daniel Alvarez Sanchez wrote:<br>&gt; &gt; On Thu, Aug 29, 2019 at 10:01 PM Mark Michelson &lt;<a href="mailto:mmichels@redhat.com">mmichels@redhat.com</a>&gt; wrote:<br>&gt; &gt;&gt;<br>&gt; &gt;&gt; On 8/29/19 2:39 PM, Numan Siddique wrote:<br>&gt; &gt;&gt;&gt; Hello Everyone,<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt; In one of the OVN deployments, we are seeing 100% CPU usage by<br>&gt; &gt;&gt;&gt; ovn-controllers all the time.<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt; After investigations we found the below<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;    - ovn-controller is taking more than 20 seconds to complete full loop<br>&gt; &gt;&gt;&gt; (mainly in lflow_run() function)<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;    - The physical switch is sending GARPs periodically every 10 seconds.<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;    - There is ovn-bridge-mappings configured and these GARP packets<br>&gt; &gt;&gt;&gt; reaches br-int via the patch port.<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;    - We have a flow in router pipeline which applies the action - put_arp<br>&gt; &gt;&gt;&gt; if it is arp packet.<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;    - ovn-controller pinctrl thread receives these garps, stores the<br>&gt; &gt;&gt;&gt; learnt mac-ips in the &#39;put_mac_bindings&#39; hmap and notifies the<br>&gt; &gt;&gt;&gt; ovn-controller main thread by incrementing the seq no.<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;    - In the ovn-controller main thread, after lflow_run() finishes,<br>&gt; &gt;&gt;&gt; pinctrl_wait() is called. This function calls - poll_immediate_wake() as<br>&gt; &gt;&gt;&gt; &#39;put_mac_bindings&#39; hmap is not empty.<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt; - This causes the ovn-controller poll_block() to not sleep at all and<br>&gt; &gt;&gt;&gt; this repeats all the time resulting in 100% cpu usage.<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt; The deployment has OVS/OVN 2.9.  We have back ported the pinctrl_thread<br>&gt; &gt;&gt;&gt; patch.<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt; Some time back I had reported an issue about lflow_run() taking lot of<br>&gt; &gt;&gt;&gt; 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><br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt; I think we need to improve the logical processing sooner or later.<br>&gt; &gt;&gt;<br>&gt; &gt;&gt; I agree that this is very important. I know that logical flow processing<br>&gt; &gt;&gt; is the biggest bottleneck for ovn-controller, but 20 seconds is just<br>&gt; &gt;&gt; ridiculous. In your scale testing, you found that lflow_run() was taking<br>&gt; &gt;&gt; 10 seconds to complete.<br>&gt; &gt; I support this statement 100% (20 seconds is just ridiculous). To be<br>&gt; &gt; precise, in this deployment we see over 23 seconds for the main loop<br>&gt; &gt; to process and I&#39;ve seen even 30 seconds some times. I&#39;ve been talking<br>&gt; &gt; to Numan these days about this issue and I support profiling this<br>&gt; &gt; actual deployment so that we can figure out how incremental processing<br>&gt; &gt; would help.<br>&gt; &gt;<br>&gt; &gt;&gt;<br>&gt; &gt;&gt; I&#39;m curious if there are any factors in this particular deployment&#39;s<br>&gt; &gt;&gt; configuration that might contribute to this. For instance, does this<br>&gt; &gt;&gt; deployment have a glut of ACLs? Are they not using port groups?<br>&gt; &gt; They&#39;re not using port groups because it&#39;s 2.9 and it is not there.<br>&gt; &gt; However, I don&#39;t think port groups would make a big difference in<br>&gt; &gt; terms of ovn-controller computation. I might be wrong but Port Groups<br>&gt; &gt; help reduce the number of ACLs in the NB database while the # of<br>&gt; &gt; Logical Flows would still remain the same. We&#39;ll try to get the<br>&gt; &gt; contents of the NB database and figure out what&#39;s killing it.<br>&gt; &gt;<br>&gt;<br><div>&gt; You&#39;re right that port groups won&#39;t reduce the number of logical flows.</div><div><br></div><div>I think port-group reduces number of logical flows significantly, and also reduces OVS flows when conjunctive matches are effective.</div>Please see my calculation here: <a href="https://www.slideshare.net/hanzhou1978/large-scale-overlay-networks-with-ovn-problems-and-solutions/30">https://www.slideshare.net/hanzhou1978/large-scale-overlay-networks-with-ovn-problems-and-solutions/30</a><div><br></div>&gt; However, it can reduce the computation in ovn-controller. The reason is<br>&gt; that the logical flows generated by ACLs that use port groups may result<br>&gt; in conjunctive matches being used. If you want a bit more information,<br>&gt; see the &quot;Port groups&quot; section of this blog post I wrote:<br>&gt;<br>&gt; <a href="https://developers.redhat.com/blog/2019/01/02/performance-improvements-in-ovn-past-and-future/">https://developers.redhat.com/blog/2019/01/02/performance-improvements-in-ovn-past-and-future/</a><br>&gt;<br>&gt; The TL;DR is that with port groups, I saw the number of OpenFlow flows<br>&gt; generated by ovn-controller drop by 3 orders of magnitude. And that<br>&gt; meant that flow processing was 99% faster for large networks.<br>&gt;<br>&gt; You may not see the same sort of improvement for this deployment, mainly<br>&gt; because my test case was tailored to illustrate how port groups help.<br>&gt; There may be other factors in this deployment that complicate flow<br>&gt; processing.<br>&gt;<br>&gt; &gt;&gt;<br>&gt; &gt;&gt; This particular deployment&#39;s configuration may give us a good scenario<br>&gt; &gt;&gt; for our testing to improve lflow processing time.<br>&gt; &gt; Absolutely!<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt; But to fix this issue urgently, we are thinking of the below approach.<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;    - pinctrl_thread will locally cache the mac_binding entries (just like<br>&gt; &gt;&gt;&gt; it caches the dns entries). (Please note pinctrl_thread can not access<br>&gt; &gt;&gt;&gt; the SB DB IDL).<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt; - Upon receiving any arp packet (via the put_arp action), pinctrl_thread<br>&gt; &gt;&gt;&gt; will check the local mac_binding cache and will only wake up the main<br>&gt; &gt;&gt;&gt; ovn-controller thread only if the mac_binding update is required.<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt; This approach will solve the issue since the MAC sent by the physical<br>&gt; &gt;&gt;&gt; switches will not change. So there is no need to wake up ovn-controller<br>&gt; &gt;&gt;&gt; main thread.<br>&gt; &gt;&gt;<br>&gt; &gt;&gt; I think this can work well. We have a lot of what&#39;s needed already in<br>&gt; &gt;&gt; pinctrl at this point. We have the hash table of mac bindings already.<br>&gt; &gt;&gt; Currently, we flush this table after we write the data to the southbound<br>&gt; &gt;&gt; database. Instead, we would keep the bindings in memory. We would need<br>&gt; &gt;&gt; to ensure that the in-memory MAC bindings eventually get deleted if they<br>&gt; &gt;&gt; become stale.<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt; In the present master/2.12 these GARPs will not cause this 100% cpu loop<br>&gt; &gt;&gt;&gt; issue because incremental processing will not recompute flows.<br>&gt; &gt;&gt;<br>&gt; &gt;&gt; Another mitigating factor for master is something I&#39;m currently working<br>&gt; &gt;&gt; on. I&#39;ve got the beginnings of a patch series going where I am<br>&gt; &gt;&gt; separating pinctrl into a separate process from ovn-controller:<br>&gt; &gt;&gt; <a href="https://github.com/putnopvut/ovn/tree/pinctrl_process">https://github.com/putnopvut/ovn/tree/pinctrl_process</a><br>&gt; &gt;&gt;<br>&gt; &gt;&gt; It&#39;s in the early stages right now, so please don&#39;t judge :)<br>&gt; &gt;&gt;<br>&gt; &gt;&gt; Separating pinctrl to its own process means that it cannot directly<br>&gt; &gt;&gt; cause ovn-controller to wake up like it currently might.<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt; Even though the above approach is not really required for master/2.12, I<br>&gt; &gt;&gt;&gt; think it is still Ok to have this as there is no harm.<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt; I would like to know your comments and any concerns if any.<br>&gt; &gt;&gt;<br>&gt; &gt;&gt; Hm, I don&#39;t really understand why we&#39;d want to put this in master/2.12<br>&gt; &gt;&gt; if the problem doesn&#39;t exist there. The main concern I have is with<br>&gt; &gt;&gt; regards to cache lifetime. I don&#39;t want to introduce potential memory<br>&gt; &gt;&gt; growth concerns into a branch if it&#39;s not necessary.<br>&gt; &gt;&gt;<br>&gt; &gt;&gt; Is there a way for us to get this included in 2.9-2.11 without having to<br>&gt; &gt;&gt; put it in master or 2.12? It&#39;s hard to classify this as a bug fix,<br>&gt; &gt;&gt; really, but it does prevent unwanted behavior in real-world setups.<br>&gt; &gt;&gt; Could we get an opinion from committers on this?<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt; Thanks<br>&gt; &gt;&gt;&gt; Numan<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt; _______________________________________________<br>&gt; &gt;&gt;&gt; discuss mailing list<br>&gt; &gt;&gt;&gt; <a href="mailto:discuss@openvswitch.org">discuss@openvswitch.org</a><br>&gt; &gt;&gt;&gt; <a href="https://mail.openvswitch.org/mailman/listinfo/ovs-discuss">https://mail.openvswitch.org/mailman/listinfo/ovs-discuss</a><br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;<br>&gt; &gt;&gt; _______________________________________________<br>&gt; &gt;&gt; discuss mailing list<br>&gt; &gt;&gt; <a href="mailto:discuss@openvswitch.org">discuss@openvswitch.org</a><br>&gt; &gt;&gt; <a href="https://mail.openvswitch.org/mailman/listinfo/ovs-discuss">https://mail.openvswitch.org/mailman/listinfo/ovs-discuss</a><br>&gt;<br>&gt; _______________________________________________<br>&gt; dev mailing list<br>&gt; <a href="mailto:dev@openvswitch.org">dev@openvswitch.org</a><br>&gt; <a href="https://mail.openvswitch.org/mailman/listinfo/ovs-dev">https://mail.openvswitch.org/mailman/listinfo/ovs-dev</a></div>