On Mon, May 01, 2017 at 03:02:33PM -0700, Han Zhou wrote: > On Mon, May 1, 2017 at 2:44 PM, Ben Pfaff <[email protected]> wrote: > > > > On Fri, Apr 21, 2017 at 06:55:28PM -0700, Han Zhou wrote: > > > As discussed in [1], what the incremental processing code > > > actually accomplished was that the ovn-controller would > > > be "quiet" and not burn CPU when things weren't changing. > > > This patch set recreates this state by calculating whether > > > changes have occured that would require a full calculation > > > to be performed. It does this by persisting a copy of > > > the localvif_to_ofport and tunnel information in the > > > controller module, rather than in the physical.c module > > > as was the case with previous commits. > > > > > > [1] > https://mail.openvswitch.org/pipermail/ovs-dev/2016-August/078272.html > > > > > > Signed-off-by: Ryan Moats <[email protected]> > > > Co-authored-by: Han Zhou <[email protected]> > > > Signed-off-by: Han Zhou <[email protected]> > > > --- > > > > > > Notes: > > > - Based on the old patch from Ryan Moats and rebased to current > master. > > > - Fixed a problem: when there are large number of flows being > installed > > > to OVS, changes made at the same time to SB DB (e.g. lflows) or > > > physical mappings won't get processed until there are new changes > to > > > trigger processing, which may not happen at all. The root cause is > > > ofctrl_put can abort temporarily if there are in-flight messages, > > > which causes last round of flow updates got lost. So > force_full_process > > > is added in that case, and checking logic changed accordingly in > the > > > main loop so that old physcal_change is preserved for next > iteration > > > in such case. This is also the reason why this patch is put into a > > > patch serie because it depends on the ofctrl_can_put() change. > > > > I'm pretty anxious about this patch, because the approach seems fragile. > > By that, I mean that it seems like it's pretty easy to change the code > > in ovn-controller in some way that means that "full processing" is > > needed, but forget to add the right call somewhere. And then what > > happens is that the bug lies dormant and only triggers in some corner > > case, and becomes very hard to debug. Do you have any thoughts on that? > > I agree it is fragile... An alternative solution to the problem is > multi-threading ovn-controller, so that lflow processing won't block (or > triggered by) other tasks such as packet-in processing from OVS. I'll > probably spend some time on it, if there is no other way better ...
I'm glad to hear that you're going to try that out. Maybe we will find out that it is a difficult solution; for example, the ovsdb IDL library is not thread safe. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
