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