[ovs-discuss] RFC: incremental computation for OVN with DDlog
zhouhan at gmail.com
Mon Nov 5 07:01:23 UTC 2018
On Fri, Nov 2, 2018 at 10:44 AM Ben Pfaff <blp at ovn.org> wrote:
> I was asked in an OVN meeting to send out an email talking about what
> we're working on to make ovn-northd and ovn-controller faster. Here's
> my summary.
Thanks Ben for the great summary!
I just have some *minor* comments on the background part.
> OVN is essentially a stack of compilers. At the top, the CMS dumps
> some configuration into the northbound database (NDBB). Then:
> 1. ovn-northd centrally translates the high-level NBDB description
> into logical flows in the southbound database (SBDB).
> 2. ovn-controller, on each HV, translates the SBDB logical flows
> into "physical" (OpenFlow) flows for the local hypervisor and
> passes them to ovs-vswitchd.
> 3. ovs-vswitchd translates OpenFlow flows into datapath flows on
> demand as traffic appears.
> Currently, OVN implements steps 1 and 2 with code that translates all
> input to output in one go. When any of the input changes, it
> re-translates all of it. This is fine for small deployments, but it
> scales poorly beyond about 1000 hypervisors, at which point each
> translation step begins to take multiple seconds. Larger deployments
> call for incremental computation, in which a small change in the input
> requires only a small amount of computation to yield a small change in
> the output.
The conclusion is true, but I'd like to comment about the scale number
"1000 hypervisors". 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.
> It is difficult to implement incremental computation in C. For
> ovn-controller, two attempts have been made already. The first attempt,
> in 2016, increased code complexity without similar benefit
> A recent approach, by Han Zhou shows a much bigger improvement, but it
> also increases complexity greatly and definitely makes maintenance more
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 :)
(As a reference, here is the branch that is rebased on 2.10:
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the discuss