As mentioned in today's OVN meeting, I observed a problem regarding megaflow effectiveness. Now I have more details but really need help from folks here. Originally I thought it is due to the way OVN is programming the flows, but now I even wonder it could be a problem in OVS (or my misunderstanding about OVS).
In this OVN setup I observed unreasonably high flow-miss rate on chassis nodes, especially the gateway nodes. Then with ovs-dpctl dump-flows I saw many udp flows installed for same match conditions expect the udp dst port, i.e. only the udp(dst=xxxxx) part is different. This would cause UDP sessions latency, since in this scenario most of those udp packets are short lived flows and all processed in slowpath. However I didn't see such problem for TCP. At first I suspected the dhcp port related flows in port-security stage could cause the megaflow always have the udp port in the match condition, but it turns out this is not the case because the dhcp flows matches the specific broadcast IP and 0.0.0.0 only. I confirmed this by debugging on the gateway node - there is no udp related flows installed at all in gateway node userspace because port-security is not relevant for gateway node, and there is no flow with tp_dst in match condition either. I verified by ovs-ofctl dump-flows br-int | grep udp. i.e., below commands returns no result: # ovs-ofctl dump-flows br-int | grep udp # ovs-ofctl dump-flows br-int | grep tp_dst # ovs-ofctl dump-flows br-int | grep tp_src So could anyone explain what could cause so many megaflows installed in datapath, each with specific udp dst port? Please find the example flows and trace, ovn-detrace output here: https://gist.github.com/hzhou8/763e18c209aab40e7f3d6bd0690cea6f Thanks, Han
_______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss