[ovs-dev] Questions about megaflow

jilei (F) jilei8 at huawei.com
Sat Oct 17 07:46:09 UTC 2020


Hi all,



The ovs ran into a problem in our  environment: Flow continuous to upcall(can not generate corresponding megaflow) , because of flow_put_on_pmd failed.



flow configuration:

ciagent-9-:/Images/fzt/ovs # ovs-ofctl show br0

OFPT_FEATURES_REPLY (xid=0x2): dpid:000070c7f2cb5874

n_tables:254, n_buffers:0

capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP

actions: output enqueue ext_action set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst

1(bond0): addr:70:c7:f2:cb:58:74

     config:     0

     state:      0

     current:    10GB-FD

     speed: 10000 Mbps now, 0 Mbps max

2(test): addr:52:ec:0b:03:38:ab

     config:     0

     state:      0

     current:    10MB-FD COPPER

     speed: 10 Mbps now, 0 Mbps max

LOCAL(br0): addr:70:c7:f2:cb:58:74

     config:     0

     state:      0

     current:    10MB-FD COPPER

     speed: 10 Mbps now, 0 Mbps max



ciagent-9-:/Images/fzt/ovs # ovs-ofctl dump-flows br0

cookie=0x0, duration=395.501s, table=0, n_packets=717, n_bytes=70266, priority=28,ip,in_port=bond0 actions=IN_PORT

cookie=0x0, duration=2015.547s, table=0, n_packets=0, n_bytes=0, priority=29,ip,nw_dst=198.159.208.0/24 actions=output:test

cookie=0x0, duration=2.763s, table=0, n_packets=0, n_bytes=0, priority=29,ip,nw_dst=139.159.208.0/24 actions=output:test



Steps to reproduce the problem:

Step1:

Generate an ip stream into bond,

SIP:1.2.1.2   DIP:130.119.101.60  Type:icmp request



A megaflow will be generated:

recirc_id(0),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(dst=130.119.101.60/248.0.0.0,frag=no), packets:751, bytes:73598, used:0.730s, actions:2



Step2:

Delete the flow of “nw_dst=139.159.208.0/24”

ovs-ofctl del-flows br0 "table=0,ip,nw_dst=139.159.208.0/24"



Note: The megaflow of 130.119.101.60 will not be changed.





Step3:

Generate another ip stream into bond,

SIP:1.2.1.2   DIP:168.119.102.61  Type:icmp request



Now, We can find that this stream cannot generate the corresponding megaflow. It will keep upcalling, and the miss counter in “ovs-appctl dpctl/show” will keep increasing. If we open the dpif’s debug, can find continuous log of “File exist”.



Root cause analysis:

The key to lookup cls in fast_path_processing(-->dp_netdev_pmd_lookup_flow) is different from the one in flow_put_on_pmd(-->dp_netdev_pmd_lookup_flow).





Is there any suggestion to fix this bug? How about the following two modifications:

1.       Use the same key to lookup cls in handler thread

---

lib/dpif-netdev.c | 10 ++++++----

1 file changed, 6 insertions(+), 4 deletions(-)



diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c

index e456cc9..facb9f6 100644

--- a/lib/dpif-netdev.c

+++ b/lib/dpif-netdev.c

@@ -3524,10 +3524,12 @@ dpif_netdev_flow_put(struct dpif *dpif, const struct dpif_flow_put *put)

     }



     /* Must produce a netdev_flow_key for lookup.

-     * Use the same method as employed to create the key when adding

-     * the flow to the dplcs to make sure they match. */

-    netdev_flow_mask_init(&mask, &match);

-    netdev_flow_key_init_masked(&key, &match.flow, &mask);

+         * Must generate key by flow to guarantee that key is the same as the key in

+         * fast_path_processing().

+         * ps: key.hash will not be used in lookup. */

+    miniflow_map_init(&key.mf, &match->flow);

+    miniflow_init(&key.mf, &match->flow);

+    key.len = netdev_flow_key_size(miniflow_n_values(&key.mf));



     if (put->pmd_id == PMD_ID_NULL) {

         if (cmap_count(&dp->poll_threads) == 0) {

--



2.       Modify the revalidate_ukey__ to delete the megaflow when mask changes



From c7bda1680832a18946b8459f6b937d62b02d0280 Mon Sep 17 00:00:00 2001

From: f00448292 <fuzhantao at huawei.com<mailto:fuzhantao at huawei.com>>

Date: Mon, 20 Jul 2020 14:44:34 +0800

Subject: [PATCH] NEW



Signed-off-by: f00448292 <fuzhantao at huawei.com<mailto:fuzhantao at huawei.com>>

---

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 8dfa05b..8a8c233 100644

--- a/ofproto/ofproto-dpif-upcall.c

+++ b/ofproto/ofproto-dpif-upcall.c

@@ -2209,7 +2209,7 @@ revalidate_ukey__(struct udpif *udpif, const struct udpif_key *ukey,

      * tells that the datapath flow is now too generic and must be narrowed

      * down.  Note that we do not know if the datapath has ignored any of the

      * wildcarded bits, so we may be overly conservative here. */

-    if (flow_wildcards_has_extra(&dp_mask, ctx.wc)) {

+    if (flow_wildcards_equal(&dp_mask, ctx.wc)) {

         goto exit;

     }



--

Looking forward to your reply.



Thanks.



More information about the dev mailing list