> On Dec 10, 2015, at 4:11 PM, Jarno Rajahalme <ja...@ovn.org> wrote: > > >> On Dec 10, 2015, at 3:20 PM, Jesse Gross <je...@kernel.org> wrote: >> >> On Wed, Dec 9, 2015 at 6:27 PM, Daniele Di Proietto >> <diproiet...@vmware.com> wrote: >>> Sometimes the ofproto layer creates a flow which is not liked by the >>> revalidation for various reasons. This behavior, while not critical >>> might impact the performance. This series aims to fix a lot of these >>> bugs. >>> >>> The detection has been done by modifying OVS to revalidate a flow as >>> soon as it is installed (this is not included in the series, I'd be >>> happy to discuss strategies to merge something like that upstream). >>> If the revalidation complains there's a bug. This series fixes all the >>> bugs found in the testsuite. >>> >>> The first commits are trivial fixes to various components in OVS. The >>> last three commits address more complicated problems and I'd be happy >>> to discuss alternative (maybe simpler) solutions. >> >> I just wanted to say that this is really great work. Thanks a lot for >> tracking all of these corner cases down! >> > > +2 > >> I think it would definitely be worthwhile to upstream your detection >> code when you have a chance. > > Maybe add ovs-appctl commands to turn on/off the immediate revalidation and > related error reporting. I have a customer bug case were this would be > immediately useful. >
What may be even more confusing is that the next full revalidation may be a long time later, if there are no events that trigger revalidation (connectivity and/or flow table changes), so the deleting of the flow in the eventual full revalidation may be that much more surprising. Jarno _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
