[ovs-discuss] Megaflow effectiveness problem
zhouhan at gmail.com
Fri Sep 7 02:07:07 UTC 2018
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:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the discuss