On Tue, Feb 2, 2016 at 4:31 PM, Russell Bryant <russ...@ovn.org> wrote: > 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 <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 >>> >>> 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". >
Acked-By: Kyle Mestery <mest...@mestery.com> > -- > Russell Bryant > _______________________________________________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
