<div dir="ltr"><div dir="ltr"><br><br>On Fri, Nov 2, 2018 at 10:44 AM Ben Pfaff &lt;<a href="mailto:blp@ovn.org">blp@ovn.org</a>&gt; wrote:<br>&gt;<br>&gt; I was asked in an OVN meeting to send out an email talking about what<br>&gt; we&#39;re working on to make ovn-northd and ovn-controller faster.  Here&#39;s<br>&gt; my summary.</div><div dir="ltr"><br></div><div>Thanks Ben for the great summary!</div><div>I just have some *minor* comments on the background part.<br></div><div><br></div><div dir="ltr">&gt;</div><div dir="ltr">&gt; OVN is essentially a stack of compilers.  At the top, the CMS dumps<br>&gt; some configuration into the northbound database (NDBB).  Then:<br>&gt;<br>&gt;     1. ovn-northd centrally translates the high-level NBDB description<br>&gt;        into logical flows in the southbound database (SBDB).<br>&gt;<br>&gt;     2. ovn-controller, on each HV, translates the SBDB logical flows<br>&gt;        into &quot;physical&quot; (OpenFlow) flows for the local hypervisor and<br>&gt;        passes them to ovs-vswitchd.<br>&gt;<br>&gt;     3. ovs-vswitchd translates OpenFlow flows into datapath flows on<br>&gt;        demand as traffic appears.<br>&gt;<br>&gt; Currently, OVN implements steps 1 and 2 with code that translates all<br>&gt; input to output in one go.  When any of the input changes, it<br>&gt; re-translates all of it.  This is fine for small deployments, but it<br>&gt; scales poorly beyond about 1000 hypervisors, at which point each<br>&gt; translation step begins to take multiple seconds.  Larger deployments<br>&gt; call for incremental computation, in which a small change in the input<br>&gt; requires only a small amount of computation to yield a small change in<br>&gt; the output.</div><div dir="ltr"><br></div><div>The conclusion is true, but I&#39;d like to comment about the scale number &quot;1000 hypervisors&quot;. In fact number of logical objects impacts more than number of hypervisors in terms of the compute for translations. E.g. with 64 lports per hypervisor, a deployment of 100 hypervisors is big enough to see scale problems, both compute latency and high CPU cost on hypervisors.<br></div><div dir="ltr"><br></div><div dir="ltr">&gt;<br>&gt; It is difficult to implement incremental computation in C.  For<br>&gt; ovn-controller, two attempts have been made already.  The first attempt,<br>&gt; in 2016, increased code complexity without similar benefit<br>&gt; (<a href="https://mail.openvswitch.org/pipermail/ovs-dev/2016-August/078272.html">https://mail.openvswitch.org/pipermail/ovs-dev/2016-August/078272.html</a>).<br>&gt; A recent approach, by Han Zhou shows a much bigger improvement, but it<br>&gt; also increases complexity greatly and definitely makes maintenance more<br><div>&gt; difficult.</div><div><br></div><div>I think my approach is less complex and more maintainable than the 2016 attempt, but I do agree it is still not easy to maintain in the long run comparing with the DDlog proposal. Maybe this is not important at all :)<br></div><div>(As a reference, here is the branch that is rebased on 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>)</div><div><br></div><div>I completely support the DDlog approach as a general solution to both northd and ovn-controller. My approach was implementing index and joins by hand, while DDlog will just do it automatically with the engine, which will be far more maintainable.<br></div><div><br></div><div>Thanks,</div><div>Han<br></div></div></div>