The revalidator process uses the internal call udpif_get_n_flows()
to get the total number of flows installed in the system. It uses
this value for various decisions on flow installation and removal.
With the tc offload this values is incorrect, as the hardware
offloaded are not included. With rte_flow offload this is not a
problem as dpif netdev keeps both in sync.
This patch will include the hardware offloaded flows if the
underlying dpif implementation is not syncing them.
Signed-off-by: Eelco Chaudron <echau...@redhat.com>
---
v3: Added this patch to patch set.
ofproto/ofproto-dpif-upcall.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c
index b83cf49ff..392f2717d 100644
--- a/ofproto/ofproto-dpif-upcall.c
+++ b/ofproto/ofproto-dpif-upcall.c
@@ -785,6 +785,17 @@ udpif_get_n_flows(struct udpif *udpif)
atomic_store_relaxed(&udpif->n_flows_timestamp, now);
dpif_get_dp_stats(udpif->dpif, &stats);
flow_count = stats.n_flows;
+
+ if (!dpif_synced_dp_layers(udpif->dpif)) {
+ /* If the dpif layer does not sync the flows, we need to include
+ * the hardware offloaded flows separately. */
+ uint64_t hw_flows;
+
+ if (!dpif_get_n_offloaded_flows(udpif->dpif, &hw_flows)) {
+ flow_count += hw_flows;
+ }
+ }
+
atomic_store_relaxed(&udpif->n_flows, flow_count);
ovs_mutex_unlock(&udpif->n_flows_mutex);
} else {
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
