<div dir="ltr"><br><br>On Fri, Jun 21, 2019 at 12:31 AM Han Zhou &lt;<a href="mailto:zhouhan@gmail.com">zhouhan@gmail.com</a>&gt; wrote:<br>&gt;<br>&gt;<br>&gt;<br>&gt; On Thu, Jun 20, 2019 at 11:42 PM Numan Siddique &lt;<a href="mailto:nusiddiq@redhat.com">nusiddiq@redhat.com</a>&gt; wrote:<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt; On Fri, Jun 21, 2019, 11:47 AM Han Zhou &lt;<a href="mailto:zhouhan@gmail.com">zhouhan@gmail.com</a>&gt; wrote:<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;<br>&gt; &gt;&gt; On Tue, Jun 11, 2019 at 9:16 AM Daniel Alvarez Sanchez &lt;<a href="mailto:dalvarez@redhat.com">dalvarez@redhat.com</a>&gt; wrote:<br>&gt; &gt;&gt; &gt;<br>&gt; &gt;&gt; &gt; Thanks a lot Han for the answer!<br>&gt; &gt;&gt; &gt;<br>&gt; &gt;&gt; &gt; On Tue, Jun 11, 2019 at 5:57 PM Han Zhou &lt;<a href="mailto:zhouhan@gmail.com">zhouhan@gmail.com</a>&gt; wrote:<br>&gt; &gt;&gt; &gt; &gt;<br>&gt; &gt;&gt; &gt; &gt;<br>&gt; &gt;&gt; &gt; &gt;<br>&gt; &gt;&gt; &gt; &gt;<br>&gt; &gt;&gt; &gt; &gt; On Tue, Jun 11, 2019 at 5:12 AM Dumitru Ceara &lt;<a href="mailto:dceara@redhat.com">dceara@redhat.com</a>&gt; wrote:<br>&gt; &gt;&gt; &gt; &gt; &gt;<br>&gt; &gt;&gt; &gt; &gt; &gt; On Tue, Jun 11, 2019 at 10:40 AM Daniel Alvarez Sanchez<br>&gt; &gt;&gt; &gt; &gt; &gt; &lt;<a href="mailto:dalvarez@redhat.com">dalvarez@redhat.com</a>&gt; wrote:<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt;<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; Hi Han, all,<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt;<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; Lucas, Numan and I have been doing some &#39;scale&#39; testing of OpenStack<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; using OVN and wanted to present some results and issues that we&#39;ve<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; found with the Incremental Processing feature in ovn-controller. Below<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; is the scenario that we executed:<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt;<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; * 7 baremetal nodes setup: 3 controllers (running<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; ovn-northd/ovsdb-servers in A/P with pacemaker) + 4 compute nodes. OVS<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; 2.10.<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; * The test consists on:<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt;   - Create openstack network (OVN LS), subnet and router<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt;   - Attach subnet to the router and set gw to the external network<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt;   - Create an OpenStack port and apply a Security Group (ACLs to allow<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; UDP, SSH and ICMP).<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt;   - Bind the port to one of the 4 compute nodes (randomly) by<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; attaching it to a network namespace.<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt;   - Wait for the port to be ACTIVE in Neutron (&#39;up == True&#39; in NB)<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt;   - Wait until the test can ping the port<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; * Running browbeat/rally with 16 simultaneous process to execute the<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; test above 150 times.<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; * When all the 150 &#39;fake VMs&#39; are created, browbeat will delete all<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; the OpenStack/OVN resources.<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt;<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; We first tried with OVS/OVN 2.10 and pulled some results which showed<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; 100% success but ovn-controller is quite loaded (as expected) in all<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; the nodes especially during the deletion phase:<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt;<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; - Compute node: <a href="https://imgur.com/a/tzxfrIR">https://imgur.com/a/tzxfrIR</a><br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; - Controller node (ovn-northd and ovsdb-servers): <a href="https://imgur.com/a/8ffKKYF">https://imgur.com/a/8ffKKYF</a><br>&gt; &gt;&gt; &gt; &gt; &gt; &gt;<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; After conducting the tests above, we replaced ovn-controller in all 7<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; nodes by the one with the current master branch (actually from last<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; week). We also replaced ovn-northd and ovsdb-servers but the<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; ovs-vswitchd has been left untouched (still on 2.10). The expected<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; results were to get less ovn-controller CPU usage and also better<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; times due to the Incremental Processing feature introduced recently.<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; However, the results don&#39;t look very good:<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt;<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; - Compute node: <a href="https://imgur.com/a/wuq87F1">https://imgur.com/a/wuq87F1</a><br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; - Controller node (ovn-northd and ovsdb-servers): <a href="https://imgur.com/a/99kiyDp">https://imgur.com/a/99kiyDp</a><br>&gt; &gt;&gt; &gt; &gt; &gt; &gt;<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; One thing that we can tell from the ovs-vswitchd CPU consumption is<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; that it&#39;s much less in the Incremental Processing (IP) case which<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; apparently doesn&#39;t make much sense. This led us to think that perhaps<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; ovn-controller was not installing the necessary flows in the switch<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; and we confirmed this hypothesis by looking into the dataplane<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; results. Out of the 150 VMs, 10% of them were unreachable via ping<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; when using ovn-controller from master.<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt;<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; @Han, others, do you have any ideas as of what could be happening<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; here? We&#39;ll be able to use this setup for a few more days so let me<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; know if you want us to pull some other data/traces, ...<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt;<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; Some other interesting things:<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; On each of the compute nodes, (with an almost evenly distributed<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; number of logical ports bound to them), the max amount of logical<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; flows in br-int is ~90K (by the end of the test, right before deleting<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; the resources).<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt;<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; It looks like with the IP version, ovn-controller leaks some memory:<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; <a href="https://imgur.com/a/trQrhWd">https://imgur.com/a/trQrhWd</a><br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; While with OVS 2.10, it remains pretty flat during the test:<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; <a href="https://imgur.com/a/KCkIT4O">https://imgur.com/a/KCkIT4O</a><br>&gt; &gt;&gt; &gt; &gt; &gt;<br>&gt; &gt;&gt; &gt; &gt; &gt; Hi Daniel, Han,<br>&gt; &gt;&gt; &gt; &gt; &gt;<br>&gt; &gt;&gt; &gt; &gt; &gt; I just sent a small patch for the ovn-controller memory leak:<br>&gt; &gt;&gt; &gt; &gt; &gt; <a href="https://patchwork.ozlabs.org/patch/1113758/">https://patchwork.ozlabs.org/patch/1113758/</a><br>&gt; &gt;&gt; &gt; &gt; &gt;<br>&gt; &gt;&gt; &gt; &gt; &gt; At least on my setup this is what valgrind was pointing at.<br>&gt; &gt;&gt; &gt; &gt; &gt;<br>&gt; &gt;&gt; &gt; &gt; &gt; Cheers,<br>&gt; &gt;&gt; &gt; &gt; &gt; Dumitru<br>&gt; &gt;&gt; &gt; &gt; &gt;<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt;<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; Looking forward to hearing back :)<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; Daniel<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt;<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; PS. Sorry for my previous email, I sent it by mistake without the subject<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; _______________________________________________<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; discuss mailing list<br>&gt; &gt;&gt; &gt; &gt; &gt; &gt; <a href="mailto:discuss@openvswitch.org">discuss@openvswitch.org</a><br>&gt; &gt;&gt; &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; &gt;<br>&gt; &gt;&gt; &gt; &gt; Thanks Daniel for the testing and reporting, and thanks Dumitru for fixing the memory leak.<br>&gt; &gt;&gt; &gt; &gt;<br>&gt; &gt;&gt; &gt; &gt; Currently ovn-controller incremental processing only handles below SB changes incrementally:<br>&gt; &gt;&gt; &gt; &gt; - logical_flow<br>&gt; &gt;&gt; &gt; &gt; - port_binding (for regular VIF binding NOT on current chassis)<br>&gt; &gt;&gt; &gt; &gt; - mc_group<br>&gt; &gt;&gt; &gt; &gt; - address_set<br>&gt; &gt;&gt; &gt; &gt; - port_group<br>&gt; &gt;&gt; &gt; &gt; - mac_binding<br>&gt; &gt;&gt; &gt; &gt;<br>&gt; &gt;&gt; &gt; &gt; So, in test scenario you described, since each iteration creates network (SB datapath changes) and router ports (port_binding changes for non VIF), the incremental processing would not help much, because most steps in your test should trigger recompute. It would help if you create more Fake VMs in each iteration, e.g. create 10 VMs or more on each LS. Secondly, when VIF port-binding happens on current chassis, the ovn-controller will still do re-compute, and because you have only 4 compute nodes, so 1/4 of the compute node will still recompute even when binding a regular VIF port. When you have more compute nodes you would see incremental processing more effective.<br>&gt; &gt;&gt; &gt;<br>&gt; &gt;&gt; &gt; Got it, it makes sense (although then worst case, it should be at<br>&gt; &gt;&gt; &gt; least what we had before and not worse but it can also be because<br>&gt; &gt;&gt; &gt; we&#39;re mixing version here: 2.10 vs master).<br>&gt; &gt;&gt; &gt; &gt;<br>&gt; &gt;&gt; &gt; &gt; However, what really worries me is the 10% VM unreachable. I have one confusion here on the test steps. The last step you described was: - Wait until the test can ping the port. So if the VM is not pingable the test won&#39;t continue?<br>&gt; &gt;&gt; &gt;<br>&gt; &gt;&gt; &gt; Sorry I should&#39;ve explained it better. We wait for 2 minutes to the<br>&gt; &gt;&gt; &gt; port to respond to pings, if it&#39;s not reachable then we continue with<br>&gt; &gt;&gt; &gt; the next port (16 rally processes are running simultaneously so the<br>&gt; &gt;&gt; &gt; rest of the process may be doing stuff at the same time).<br>&gt; &gt;&gt; &gt;<br>&gt; &gt;&gt; &gt; &gt;<br>&gt; &gt;&gt; &gt; &gt; To debug the problem, the first thing is to identify what flows are missing for the VMs that is unreachable. Could you do ovs-appctl ofproto/trace for the ICMP flow of any VM with ping failure? And then, please enable debug log for ovn-controller with ovs-appctl -t ovn-controller vlog/set file:dbg. There may be too many logs so please enable it for as short time as any VM with ping failure is reproduced. If the last step &quot;wait until the test can ping the port&quot; is there then it should be able to detect the first occurrence if the VM is not reachable in e.g. 30 sec.<br>&gt; &gt;&gt; &gt;<br>&gt; &gt;&gt; &gt; We&#39;ll need to hack a bit here but let&#39;s see :)<br>&gt; &gt;&gt; &gt; &gt;<br>&gt; &gt;&gt; &gt; &gt; In the ovn-scale-test we didn&#39;t have data plane test, but this problem was not seen in our live environment either, with a far larger scale. The major difference in your test v.s. our environment are:<br>&gt; &gt;&gt; &gt; &gt; - We are runing with an older version. So there might be some rebase/refactor problem caused this. To eliminate this, I&#39;d suggest to try a branch I created for 2.10 (<a href="https://github.com/hzhou8/ovs/tree/ip12_rebase_on_2.10">https://github.com/hzhou8/ovs/tree/ip12_rebase_on_2.10</a>), which matches the base test you did which is also 2.10. It may also eliminate compatibility problem, if there is any, between OVN master branch and OVS 2.10 as you mentioned is used in the test.<br>&gt; &gt;&gt; &gt; &gt; - We don&#39;t use Security Group (I guess the  ~90k OVS flows you mentioned were mainly introduced by the Security Group use, if all ports were put in same group). The incremental processing is expected to be correct for security-groups, and handling it incrementally because of address_set and port_group incremental processing. However, since the testing only relied on the regression tests, I am not 100% sure if the test coverage was sufficient. So could you try disabling Security Group to rule out the problem?<br>&gt; &gt;&gt; &gt;<br>&gt; &gt;&gt; &gt; Ok will try to repeat the tests without the SGs.<br>&gt; &gt;&gt; &gt; &gt;<br>&gt; &gt;&gt; &gt; &gt; Thanks,<br>&gt; &gt;&gt; &gt; &gt; Han<br>&gt; &gt;&gt; &gt;<br>&gt; &gt;&gt; &gt; Thanks once again!<br>&gt; &gt;&gt; &gt; Daniel<br>&gt; &gt;&gt;<br>&gt; &gt;&gt; Hi Daniel,<br>&gt; &gt;&gt;<br>&gt; &gt;&gt; Any updates? Do you still see the 10% VM unreachable<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;<br>&gt; &gt;&gt; Thanks,<br>&gt; &gt;&gt; Han<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt; Hi Han,<br>&gt; &gt;<br>&gt; &gt; As such there is no datapath impact. After increasing the ping wait timeout value from 120 seconds to 180 seconds its 100% now.<br>&gt; &gt;<br>&gt; &gt; But the time taken to program the flows is too huge when compared to OVN master without IP patches.<br>&gt; &gt; Here is some data -  <a href="http://paste.openstack.org/show/753224/">http://paste.openstack.org/show/753224/</a> .  I am still investigating it. I will update my findings in some time.<br>&gt; &gt;<br>&gt; &gt; Please see the times for the action - vm.wait_for_ping<br>&gt; &gt;<br>&gt;<br><div>&gt; Thanks Numan for the investigation and update. Glad to hear there is no correctness issue, but sorry for the slowness in your test scenario. I expect that the operations in your test trigger recomputing and the worst case should be similar performance as withour I-P. It is weird that it turned out so much slower in your test. There can be some extra overhead when it tries to do incremental processing and then fallback to full recompute, but it shouldn&#39;t cause that big difference. It might be that for some reason the main loop iteration is triggered more times unnecessarily. I&#39;d suggest to compare the coverage counter &quot;lflow_run&quot; between the tests, and also check perf report to see if the hotspot is somewhere else. (Sorry that I can&#39;t provide full-time help now since I am still on vacation but I will try to be useful if things are blocked)</div><div><br></div><div>Hi Numan/Daniel, do you have any new findings on why I-P got worse result in your test? The extremely long latency (2 - 3 min) shown in your report reminds me a similar problem I reported before: <a href="https://mail.openvswitch.org/pipermail/ovs-dev/2018-April/346321.html">https://mail.openvswitch.org/pipermail/ovs-dev/2018-April/346321.html</a></div><div><br></div><div>The root cause of that problem was still not clear. In that report, the extremely long latency (7 min) was observed without I-P and it didn&#39;t happen with I-P. If it is the same problem, then I suspect it is not related to I-P or non I-P, but some problem related to ovsdb monitor condition change. To confirm if it is same problem, could you:</div><div>1. pause the test when the scale is big enough (e.g. when the test is almost completed), and then<br></div><div>2. enable ovn-controller debug log, and then<br></div><div>3. run one more iteration of the test, and see if the time was spent on waiting for SB DB update notification.</div><div><br></div><div>Please ignore my speculation above if you already found the root cause and it would be great if you could share it :)<br></div><div><br></div><div>Thanks,</div><div>Han<br></div></div>