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@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.
_______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
