On 30 August 2016 at 18:47, 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 commit adds a facility to detect > this issue early and log a warning. > > The detection is done by revalidating a flow as soon as it is installed. > Since this extra revalidation might be expensive it is disabled by > default. It can be enabled using the undocumented unixctl: > > `ovs-appctl upcall/instant-revalidation sample_rate` > > where 'sample_rate' is a number between 0 and 100, meaning the > percentage of newly installed flows that are instantly revalidated. > > We explicitly enable the feature in the unit and system tests (except > for three MPLS unit tests, which expose a problem that hasn't been fixed > yet); > > Signed-off-by: Daniele Di Proietto <diproiet...@vmware.com>
This is great idea, and it's clearly showing itself to be useful for finding real bugs. I think that for the kernel datapath codepath, there's still cases where the ukey exists in the upcall but wasn't installed - (upcall->ukey && !upcall->ukey_persists). Is it intended to also run in this case? revalidate_ukey() is already kinda hard to track, and I feel like adding an extra "instant_revalidation" bool complicates it further. I took a stab at trying to refactor this code, which I hoped would allow you to simplify your logic by just using the logic for translating a ukey into a translated flow. I think the resulting revalidate_ukey__() is pretty close to what you want here, but I would appreciate any feedback on that: http://openvswitch.org/pipermail/dev/2016-September/079778.html _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
