diff mbox series

[ovs-dev,ovs-dev,v1,3/4] ofproto-dpif-upcall: new ukey needs to take the old ukey's dump seq

Message ID 20220604143530.65815-3-hepeng.0320@bytedance.com
State Superseded
Headers show
Series [ovs-dev,ovs-dev,v1,1/4] ofproto-dpif-upcall: fix push_dp_ops | expand

Commit Message

Peng He June 4, 2022, 2:35 p.m. UTC
The userspace datapath mananges all the magaflows by a cmap. The cmap
data structrue will grow/shrink during the datapath processing and it
will re-position megaflows. This might result in two revalidator threads
might process a same megaflow during one dump stage.

Consider a situation that, revalidator 1 processes a megaflow A, and
decides to delete it from the datapath, at the mean time, this megaflow
A is also queued in the process batch of revalidator 2. After A is
deleted from datapath, revalidator 2 will take the stats info from
A and contribute to the OpenFlow rules' stats. Now it's ok for
revalidator 2 to process the old megaflow A again, even it's deleted, as
the corresponding ukey's state is UKEY_EVICTED, and its dump_seq shows
it's already dumped.

Assume that right after A is deleted, a PMD thread generates again
a new megaflow B which has the same match and action of A. The ukey
of megaflow B will replace the one of megaflow A. Now the ukey B is
new to the revalidator system.

Now since ukey B is newly generated, the revalidator will count the
stats info as new, and contribute the old megaflow A's stats again
into the OpenFlow rules' stats, this results in an inconsistent stats
between ukeys and megaflows.

To fix this, the newly generated the ukey B should take the dump_seq
of replaced A to avoid a same megaflow being revalidated twice in one
dump stage.

We observe in the production environment, the OpenFlow rules' stats
sometimes are amplified compared to the actual value.

Signed-off-by: Peng He <hepeng.0320@bytedance.com>
---
 ofproto/ofproto-dpif-upcall.c | 1 +
 1 file changed, 1 insertion(+)
diff mbox series

Patch

diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c
index 9c55e43c1..791606cc1 100644
--- a/ofproto/ofproto-dpif-upcall.c
+++ b/ofproto/ofproto-dpif-upcall.c
@@ -1868,6 +1868,7 @@  try_ukey_replace(struct umap *umap, struct udpif_key *old_ukey,
             ovs_mutex_lock(&new_ukey->mutex);
             cmap_replace(&umap->cmap, &old_ukey->cmap_node,
                          &new_ukey->cmap_node, new_ukey->hash);
+            new_ukey->dump_seq = old_ukey->dump_seq;
             ovsrcu_postpone(ukey_delete__, old_ukey);
             transition_ukey(old_ukey, UKEY_DELETED);
             transition_ukey(new_ukey, UKEY_VISIBLE);