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 ... Thanks, Han _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
