Flows which are deleted during the revalidator "dump" phase have their
corresponding dump seq updated, which leads to such ukeys being handled
by the "UKEY_KEEP" logic in revalidator_sweep__() here:
} else if (!seq_mismatch) {
result = UKEY_KEEP;
}
In practice, this has allowed the flow to be deleted in revalidate(),
then skip the flow deletion step in revalidator_sweep__(), and finally
delete the ukey itself at the end of revalidator_sweep__().
However, this is also misleading because the ukeys which are being
deleted are considered under the "UKEY_KEEP" logic. Since commit
83b03fe05e7a ("ofproto-dpif-upcall: Avoid double-delete of ukeys."),
this logic is no longer required to prevent double-deletion of such
flows, so we can now make this codepath more straightforward.
Signed-off-by: Joe Stringer <j...@ovn.org>
---
ofproto/ofproto-dpif-upcall.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c
index 69a04c9a50ca..d61113176842 100644
--- a/ofproto/ofproto-dpif-upcall.c
+++ b/ofproto/ofproto-dpif-upcall.c
@@ -2253,7 +2253,7 @@ revalidator_sweep__(struct revalidator *revalidator, bool
purge)
seq_mismatch = (ukey->dump_seq != dump_seq
&& ukey->reval_seq != reval_seq);
- if (purge) {
+ if (purge || !flow_exists) {
result = UKEY_DELETE;
} else if (!seq_mismatch) {
result = UKEY_KEEP;
--
2.1.4
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
