[ovs-discuss] [issure]actions not updated after flow changing in specific situation

[Zhengjingzhou]

Env:
CentOS Linux release 7.4.1708 (Core)  3.10.0-693.11.6.el7.x86_64
ovs-2.7.3
dpdk-devel-16.11.2-4

./configure CFLAGS="-g" --with-dpdk

echo 1024 >/sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
/usr/local/share/openvswitch/scripts/ovs-ctl start

Do a test:

ovs-vsctl add-br br1 -- set bridge br1 datapath_type=netdev
ovs-vsctl add-port br1 tap0 -- set interface tap0 type=dpdkvhostuser   // virsh create with ip 10.0.0.1, ofp:1
ovs-vsctl add-port br1 hnic1 -- set interface hnic1 type=internal       // ofp:2
ifconfig hnic1 10.0.0.2

ovs-ofctl add-flow br1 "in_port=1,icmp actions=NORMAL"
ping 10.0.0.2   vm ping hnic1                              //ping stream , keep pinging, do not exit in a whole test
ovs-ofctl del-flows br1 "in_port=1"
ovs-ofctl add-flow br1 "in_port=1 actions=output:2"     // 2 is hnic1
iperf3 -c 10.0.0.2 -t 0                              // vm to hnic1 tcp stream, keep going
ovs-ofctl del-flows br1 "in_port=1"
ovs-ofctl add-flow br1 "in_port=1 actions=output:111"   //change the actions to an inexist port,so the ping stream and tcp stream should all interruputed, and update the actions to drop

But the actually result is ,  tcp stream interrupted, but ping stream keep working fine.

Ovs-appctl dpctl/dump-flows -m netdev at ovs-netdev  shows the 2 flows of the streams above before the last output:111 add-flow executed
ufid:19ccbfc4-fa1f-47cb-841f-569c4a3cfeb4, skb_priority(0/0),skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),recirc_id(0),dp_hash(0/0),in_port(tap11),eth(src=fa:16:3e:01:01:01,dst=4e:fa:98:58:dd:f1),eth_type(0x0800),ipv4(src=10.0.0.1/0.0.0.0,dst=10.0.0.2/0.0.0.0,proto=6/0,tos=0/0,ttl=64/0,frag=no),tcp(src=43140/0,dst=5201/0), packets:6264, bytes:365499448, used:0.011s, actions:3
ufid:5c16ce76-bf9f-43eb-bada-aea903b67531, skb_priority(0/0),skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),recirc_id(0),dp_hash(0/0),in_port(tap11),eth(src=fa:16:3e:01:01:01,dst=4e:fa:98:58:dd:f1),eth_type(0x0800),ipv4(src=10.0.0.1/0.0.0.0,dst=10.0.0.2/0.0.0.0,proto=1,tos=0/0,ttl=64/0,frag=no),icmp(type=8/0,code=0/0), packets:84, bytes:8232, used:0.744s, actions:3

after the last add-flow submitted,it changed :
ufid:19ccbfc4-fa1f-47cb-841f-569c4a3cfeb4, skb_priority(0/0),skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),recirc_id(0),dp_hash(0/0),in_port(tap11),eth(src=fa:16:3e:01:01:01,dst=4e:fa:98:58:dd:f1),eth_type(0x0800),ipv4(src=10.0.0.1/0.0.0.0,dst=10.0.0.2/0.0.0.0,proto=6/0,tos=0/0,ttl=64/0,frag=no),tcp(src=43140/0,dst=5201/0), packets:6264, bytes:365499448, used:0.011s, actions:drop
ufid:5c16ce76-bf9f-43eb-bada-aea903b67531, skb_priority(0/0),skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),recirc_id(0),dp_hash(0/0),in_port(tap11),eth(src=fa:16:3e:01:01:01,dst=4e:fa:98:58:dd:f1),eth_type(0x0800),ipv4(src=10.0.0.1/0.0.0.0,dst=10.0.0.2/0.0.0.0,proto=1,tos=0/0,ttl=64/0,frag=no),icmp(type=8/0,code=0/0), packets:84, bytes:8232, used:0.744s, actions:3

Only the tcpstream changed the actions to drop cuase of the inexsit output 111, ping stream keep the old action(why?)

However afer some debug and research, I've found the key code in function flow_put_on_pmd, the way to find an exact flow :
netdev_flow = dp_netdev_pmd_lookup_flow(pmd, key, NULL);

And in my test situation, passed icmp stream key, and returned the tcpstream flow(with debug watching ufid), so it updated the tcp stream actions twice, but didn't update the ping stream at all.

Here is the conclution:

1.       Why ovs use key to find an exact flow in a modify situation while using ufid to find a exact flow in del situation( in flow_del_on_pmd function, it use dp_netdev_pmd_find_flow with ufid compare)

2.       The comment of dpcls_lookup function seems like it was an alternative searching method? Especially the "instead part",  maybe it is not exactly match enouph .

* This function is optimized for use in the userspace datapath and therefore

* does not implement a lot of features available in the standard

* classifier_lookup() function.  Specifically, it does not implement

* priorities, instead returning any rule which matches the flow.



3.       The issure only occurs in netdev datapath, the system datapath works fine.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20190627/f6e2f736/attachment.html>