One of the reasons that xlate_cache was introduced was to ensure that
statistics were attributed to the correct rules and interfaces according
to the flow that was installed into the datapath, rather than according
to the current state of the flow table.

This patch makes the revalidators use the xlate_cache to attribute stats
when full revalidation is required, as the statistics belong to the old
ruleset. However, when revalidating, the rules may have changed while
leaving the datapath flows intact, so we still re-create the xcache at
that point.

Signed-off-by: Joe Stringer <joestrin...@nicira.com>
---
v3: Clear the xcache when revalidating.
v2: Don't delete the old xcache when revalidating.
    Removed extraneous "ukey->xcache = NULL".
    Reset may_learn when pushing stats.
---
 ofproto/ofproto-dpif-upcall.c |   16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c
index 90e18e3..67a0ed8 100644
--- a/ofproto/ofproto-dpif-upcall.c
+++ b/ofproto/ofproto-dpif-upcall.c
@@ -1148,10 +1148,17 @@ revalidate_ukey(struct udpif *udpif, struct udpif_key 
*ukey,
     }
 
     may_learn = push.n_packets > 0;
-    if (ukey->xcache && !udpif->need_revalidate) {
+    if (ukey->xcache) {
         xlate_push_stats(ukey->xcache, may_learn, &push);
-        ok = true;
-        goto exit;
+        if (udpif->need_revalidate) {
+            xlate_cache_clear(ukey->xcache);
+            push.n_packets = 0;
+            push.n_bytes = 0;
+            may_learn = false;
+        } else {
+            ok = true;
+            goto exit;
+        }
     }
 
     error = xlate_receive(udpif->backer, NULL, ukey->key, ukey->key_len, &flow,
@@ -1160,9 +1167,6 @@ revalidate_ukey(struct udpif *udpif, struct udpif_key 
*ukey,
         goto exit;
     }
 
-    if (udpif->need_revalidate) {
-        xlate_cache_clear(ukey->xcache);
-    }
     if (!ukey->xcache) {
         ukey->xcache = xlate_cache_new();
     }
-- 
1.7.10.4

_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Reply via email to