On Thu, Jan 21, 2016 at 03:21:00PM -0500, Russell Bryant wrote:
> Previously, ovn-controller translated logical flows into OpenFlow flows
> for *every* logical datapath.  This patch makes it so we skip doing so
> for the egress pipeline if the datapath is a logical switch with no
> logical ports bound locally.  In that case, the flows have no effect.
> 
> This was the code path taking the most time in a large scale OVN
> environment and was an easy optimization to make based on the existing
> local_datapaths info.
> 
> In this environment, while idling, ovn-controller was taking up about
> 20% CPU with this patch, while other nodes were in the 40-70% range.
> 
> Reported-at: https://bugs.launchpad.net/networking-ovn/+bug/1536003
> Signed-off-by: Russell Bryant <russ...@ovn.org>
> Tested-by: Matt Mulsow <mailto:mamul...@us.ibm.com>
> ---
> 
> 
> As discussed in the OVN IRC meeting today, this is one patch I came up
> with while trying to analyze the performance in a large scale OVN
> test setup.  It made a big impact for not much code.  I know Ben had some
> suggestions for how to clean this up, so I'm just submitting as RFC for now.

I think this is fine for now; we can optimize more later.

However I get a compile error against current master, perhaps it has
moved on since you posted the patch:

    ../ovn/controller/ovn-controller.c: In function ‘main’:
    ../ovn/controller/ovn-controller.c:300:54: error: ‘local_datapaths’ 
undeclared (first use in this function)
                 lflow_run(&ctx, &flow_table, &ct_zones, &local_datapaths);
                                                          ^
    ../ovn/controller/ovn-controller.c:300:54: note: each undeclared identifier 
is reported only once for each function it appears in


I think that the way to optimize this, in the end, is to use a kind of
"flood fill" algorithm:

    1. Initialize set S to the logical datapaths that have a port
       located on the hypervisor.

    2. For each patch port P in a logical datapath in S, add the logical
       datapath of the remote end of P to S.

Extra credit if there's a way to infer (or specify) that a logical
datapath is "terminal", that is, that a packet that comes into it from a
different logical datapath will never come back out.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Reply via email to