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

[Russell Bryant]

On 02/02/2016 05:21 PM, Ben Pfaff wrote:
> On Tue, Feb 02, 2016 at 05:01:35PM -0500, Russell Bryant wrote:
>> On 02/02/2016 04:49 PM, Ben Pfaff wrote:
>>> 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
>>
>> Yeah, I actually wrote this on top of this patch series:
>>
>> https://patchwork.ozlabs.org/bundle/russellb/localnet/
>>
>> mainly because the scale test environment had those patches applied.
>>
>>> 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.
>>
>> right, because #2 needs to happen on every datapath added as a result of
>> #2, as well.
> 
> Yes, I forgot to mention that #2 iterates until you reach a fixed point.
> 
> I guess I'll ack this quickly when it reaches non-RFC.
> 

You can ACK it now if you're happy with it and you'd like to skip the
formality.  I was only going to update comment text based on our
discussion here about "flood fill".

-- 
Russell Bryant