<div dir="ltr"><div>Running oproto/trace unfortunately does not explain why OVS chose to look at these fields. <br></div><div>Using the same setup, for example:</div><div><br></div><div>#  ovs-appctl ofproto/trace br0 in_port=a-blue,dl_src=11:22:33:44:55:66,dl_dst=aa:bb:cc:dd:ee:ff,ipv4,nw_src=1.2.3.4<br>Flow: ip,in_port=4,vlan_tci=0x0000,dl_src=11:22:33:44:55:66,dl_dst=aa:bb:cc:dd:ee:ff,nw_src=1.2.3.4,nw_dst=0.0.0.0,nw_proto=0,nw_tos=0,nw_ecn=0,nw_ttl=0<br><br>bridge("br0")<br>-------------<br> 0. in_port=4, priority 32768<br>    output:5<br><br>Final flow: unchanged<br>Megaflow: recirc_id=0,eth,ip,in_port=4,nw_frag=no<br>Datapath actions: 3<br></div><div><br></div><div>It seems that the OpenFlow rule (not to be confused with the megaflow entry) was correctly identified, and no other actions take place. <br></div><div>Since the relevant OpenFlow rule has nothing to do with the IP layer, I don't understand why the megaflow is aware of it.</div><div><br></div><div>I'll try to look at the classifier/megaflow code (?) tomorrow, but I'd like to know if there's a high-level way to avoid such trouble.</div><div><br></div><div>Thanks<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 8 Jan 2020 at 00:39, Ben Pfaff <<a href="mailto:blp@ovn.org">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 Tue, Jan 07, 2020 at 10:44:57PM +0200, Matan Rosenberg wrote:<br>
> Acutally, I do think I have a megaflow (or other caching) issue.<br>
> <br>
> We use OVS for L2 packet forwarding; that is, given a packet, we don't need<br>
> OVS to look at other protocols beyond the Ethernet layer.<br>
> Additionally, we use VXLAN to establish L2 overlay networks across multiple<br>
> OVS servers.<br>
> <br>
> Just to make thing clear, these are some typical flow rules that you might<br>
> see on a bridge:<br>
> <br>
> - in_port=1,actions=2,3<br>
> - in_port=42,actions=FLOOD<br>
> - actions=NORMAL<br>
> <br>
> No IP matching, conntrack, etc.<br>
> <br>
> We're experiencing severe performance issues with OVS - in this use case,<br>
> it cannot handle more than couple thousand packets/s.<br>
> After some exploring, I've noticed that the installed megaflows try to<br>
> match on fields that are not present in the rules, apparently for no reason.<br>
> Here's a complete example to reproduce, using OVS 2.12.0:<br>
> <br>
> # 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>
> <br>
> # ovs-vsctl add-br br0<br>
> # 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>
> <br>
> After injecting ~100 random packets (IP, IPv6, TCP, UDP, ARP with random<br>
> addresses) to one of the red interfaces (with <a href="https://pastebin.com/Y6dPFCKJ" rel="noreferrer" target="_blank">https://pastebin.com/Y6dPFCKJ</a>),<br>
> these are the installed flows:<br>
> # ovs-dpctl dump-flows<br>
> recirc_id(0),in_port(2),eth(),eth_type(0x0806), packets:54, bytes:2268,<br>
> used:1.337s, actions:3<br>
> recirc_id(0),in_port(2),eth(),eth_type(0x86dd),ipv6(frag=no), packets:28,<br>
> 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,<br>
> bytes:610, used:1.270s, flags:S, actions:3<br>
> <br>
> As you can see, for some reason, OVS had split the single relevant OpenFlow<br>
> rule to three separate megaflows, one for each eth_type (and even other<br>
> fields - IP fragmentation?).<br>
> In my production scenario, the packets are even more diversified, and we<br>
> see OVS installing flows which match on even more fields, including<br>
> specific Ethernet and IP addresses.<br>
> <br>
> This leads to a large number of flows that have extremely low hit rate -<br>
> each flow handles not more than ~100 packets (!) during its entire lifetime.<br>
> <br>
> We suspect that this causes the performance peanalty; either<br>
> 1) The EMC/megaflow table is full, so vswitchd upcalls are all over the<br>
> place, or<br>
> 2) The huge number of inefficient megaflows leads to terrible lookup times<br>
> in the in-kernel megaflow table itslef (due to large number of masks, etc.)<br>
> <br>
> In short: how can I just make OVS oblivious to these fields? Why does it<br>
> try to match on irrlevant fields?<br>
<br>
I can see how this would be distressing.<br>
<br>
You can use ofproto/trace with a few examples to help figure out why OVS<br>
is matching on more fields than you expect.<br>
</blockquote></div>