<div dir="ltr"><div dir="ltr"><div>Acutally, I do think I have a megaflow (or other caching) issue.</div><div><br></div><div>We use OVS for L2 packet forwarding; that is, given a packet, we don't need OVS to look at other protocols beyond the Ethernet layer.</div><div>Additionally, we use VXLAN to establish L2 overlay networks across multiple OVS servers.</div><div><br></div><div>Just to make thing clear, these are some typical flow rules that you might see on a bridge:</div><div><br></div><div>- in_port=1,actions=2,3</div><div>- in_port=42,actions=FLOOD</div><div>- actions=NORMAL</div><div><br></div><div>No IP matching, conntrack, etc.<br></div><div><br></div><div>We're experiencing severe performance issues with OVS - in this use case, it cannot handle more than couple thousand packets/s.</div><div>After some exploring, I've noticed that the installed megaflows try to match on fields that are not present in the rules, apparently for no reason.<br></div><div>Here's a complete example to reproduce, using OVS 2.12.0:</div><div><br></div><div># ip link add dev a-blue type veth peer name a-red<br># ip link add dev b-blue type veth peer name b-red<br></div><div><br></div><div># ovs-vsctl add-br br0<br></div><div># ovs-vsctl add-port br0 a-blue<br># ovs-vsctl add-port br0 b-blue<br><br># ovs-ofctl del-flows br0<br># ovs-ofctl add-flow br0 in_port=a-blue,actions=b-blue<br># ovs-ofctl add-flow br0 in_port=b-blue,actions=a-blue<br></div><div><br></div><div>After injecting ~100 random packets (IP, IPv6, TCP, UDP, ARP with random addresses) to one of the red interfaces (with <a href="https://pastebin.com/Y6dPFCKJ">https://pastebin.com/Y6dPFCKJ</a>), these are the installed flows:</div><div></div><div># ovs-dpctl dump-flows<br>recirc_id(0),in_port(2),eth(),eth_type(0x0806), packets:54, bytes:2268, used:1.337s, actions:3<br>recirc_id(0),in_port(2),eth(),eth_type(0x86dd),ipv6(frag=no), packets:28, bytes:1684, used:1.430s, flags:S, actions:3<br>recirc_id(0),in_port(2),eth(),eth_type(0x0800),ipv4(frag=no), packets:15, bytes:610, used:1.270s, flags:S, actions:3<br></div><div><br></div><div>As you can see, for some reason, OVS had split the single relevant OpenFlow rule to three separate megaflows, one for each eth_type (and even other fields - IP fragmentation?).</div><div>In my production scenario, the packets are even more diversified, and we see OVS installing flows which match on even more fields, including specific Ethernet and IP addresses.</div><div><br></div><div>This leads to a large number of flows that have extremely low hit rate - each flow handles not more than ~100 packets (!) during its entire lifetime.</div><div><br></div><div>We suspect that this causes the performance peanalty; either <br></div><div>1) The EMC/megaflow table is full, so vswitchd upcalls are all over the place, or</div><div>2) The huge number of inefficient megaflows leads to terrible lookup times in the in-kernel megaflow table itslef (due to large number of masks, etc.)</div><div></div><div><br></div><div>In short: how can I just make OVS oblivious to these fields? Why does it try to match on irrlevant fields?</div><div><br></div><div>Thanks,</div><div>Matan<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 19 Dec 2019 at 02:19, Ben Pfaff <<a href="mailto:blp@ovn.org" target="_blank">blp@ovn.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Dec 18, 2019 at 04:26:09PM +0200, Matan Rosenberg wrote:<br>
> Hey,<br>
> I'm using ovs for L2 tunneling (across lots of endpoints and several ovs<br>
> nodes), and experiencing some unexpected performance issues (can't get more<br>
> that a couple thousand packets/s on rather beefy servers).<br>
> <br>
> I've come across the talk about megaflow issues in OVSFall2018, and I<br>
> suspect that it might be applicable to my situation.<br>
> <br>
>  Is there any way to view the megaflows and masks currently used by the<br>
> kernel datapath?<br>
<br>
I can't see how this would be a megaflow problem, but either way:<br>
<br>
ovs-dpctl dump-flows<br>
</blockquote></div>
</div>