[ovs-dev] [RFC] ovn-controller: Only process lflows for localdatapaths.

[Ben Pfaff]

I see that now that I'm reviewing the prerequisite patch.

On Tue, Feb 02, 2016 at 09:55:15PM +0000, Ryan Moats wrote:
> That's why I said a patch set series - this patch was based on top of another
> patch.  Applying this patch by itself results in the compile error you are
> seeing...
>  
> Ryan
>  
> 
>     ----- Original message -----
>     From: Ben Pfaff <blp at ovn.org>
>     Sent by: "dev" <dev-bounces at openvswitch.org>
>     To: Russell Bryant <russell at ovn.org>
>     Cc: dev at openvswitch.org
>     Subject: Re: [ovs-dev] [RFC] ovn-controller: Only process lflows for local
>     datapaths.
>     Date: Tue, Feb 2, 2016 3:50 PM
>      
>     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 <russell at ovn.org>
>     > Tested-by: Matt Mulsow <mailto:mamulsow at 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 at openvswitch.org
>     http://openvswitch.org/mailman/listinfo/dev
> 
>  
>