Sorry for the partial repeat, but my previous reply bounced off of dev and then I realized that I hit send too soon...
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... I'm trying to wrap my head around how the flood fill would improve things when I have lots of instances attached to a single network... Ryan "dev" <dev-boun...@openvswitch.org> wrote on 02/02/2016 03:49:57 PM: > From: Ben Pfaff <b...@ovn.org> > To: Russell Bryant <russ...@ovn.org> > Cc: dev@openvswitch.org > Date: 02/02/2016 03:50 PM > Subject: Re: [ovs-dev] [RFC] ovn-controller: Only process lflows for > local datapaths. > Sent by: "dev" <dev-boun...@openvswitch.org> > > 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 _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
