<div dir="ltr"><div>Thanks for the quick responses.</div><div><br></div><div>Levi - you'd provided a lot of info, I'm still looking into some of the points. At time point, this is what I know:<br></div><div><br></div><div>1)  No, Scapy is used only to create the packets. I can make a very diverse cap and then send it with tcpreplay, it should be fast enough - I'll look into it.</div><div></div><div>2) In general, I don't think that the veth pair performance is the bottleneck here.<br></div><div>3) In production, according to dpctl/dump-flows I see ~7k megaflows, and about ~3k masks (!). The hit/pkt is around 1k, which is <b>huge</b>.<br></div><div>4) About the TCP offloading: I don't think this is it, but I'll check.</div><div><br></div><div>Ben - I've taken a second look at the megaflows in production, and mapped the fields that are matched beyond the default dl_type and IP fragmentation.</div><div>I have some bridges with flood rules, some with normal (MAC learning), and some of them also contain vxlan ports (remote_ip and vni are defined per port, not flow based).</div><div><br></div><div>The fields that I see matched are:</div><div><br></div><div>Both actions=flood/normal (or even just output to manually specified ports):<br></div><div><ul><li>VLAN IDs <br></li><ul><li>We use about 3K vlans out of the available 4K vlan range, so it's quite a lot.</li><li>Most of the traffic is vlan tagged, so this applies to most megaflows.</li><li>Just to clarify, I don't actually need OVS to care about the vlans.<br></li></ul><li>If a packet is vlan-tagged, it's eth_type and fragmentation is also matched via encap(eth_type(...)).</li><ul><li>This makes a cartesian product: the handful eth_types we have times the number of active vlans.</li></ul><li>Tunnel-related fields, but that's normal for the vxlan ports.</li><li>I also see some other IP flags being matched, like tos and tclass.<br></li></ul><div>Only with actions=normal (MAC learning):<br></div><ul><li>I obviously also see dl_src/dst addresses, which is sensible.</li><li>Additionaly, I see OVS matching against specific ARP fields (for example, src/dst IP).</li></ul><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 8 Jan 2020 at 02:25, Levente Csikor <<a href="mailto:levente.csikor@gmail.com" target="_blank">levente.csikor@gmail.com</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">Hi Matan,<br>
<br>
I guess you were referring to my talk at OVS Fall 2018 :)<br>
As Ben has pointed out in his last email, even you are matching only on<br>
the in_port, because of your (not-manually-inserted) default drop<br>
rule(s), you will still have a couple of megaflow entries to handle<br>
different packets (as you could see, usually they are an IPv6 related<br>
discovery message and an ARP).<br>
<br>
Before going into the megaflow cache code, according to your setup,<br>
could you confirm the following things?<br>
<br>
1) by using scapy for generating the packets, are you actually able to<br>
achieve the intended packet rate at the generator?<br>
<br>
2) if YES: without OVS, can you see at the other end of your veth pair<br>
the performance you are having for generation?<br>
----<br>
These two things can easily be the bottleneck, so we have to justify<br>
that they are not the bad guys in your case.<br>
<br>
<br>
3) After checking the megaflow entries with the command Ben has shared<br>
(ovs-dpctl show/dump-flows), how many entries/masks did you see?<br>
(Note, I did not go through thoroughly your flow rules and packets)<br>
If the number is just a handful, then megaflow won't be you issue!<br>
If the number is more than ~100, it still would not be an issue,<br>
however if it is then it can be caused by two reasons:<br>
 - you are using an OVS (version), which is delivered by your<br>
distribution -> we realized (in 2018 with Ben et al.) that the default<br>
kernel module coming with the distribution has the microflow cache<br>
switched OFF (the main networking guys responsible for the kernel<br>
modules are not a huge fans of caching) - so you either enable it<br>
(somehow if possible) or simply install OVS from source.<br>
 - OR there are still some issues with your VETHS! we experienced such<br>
a bad performance with relatively low number of masks and traffic, if<br>
TCP offload was switched off on the physical NIC, or when we were using<br>
UDP packets (as there is no offloading function for UDP).<br>
Have you tried playing these values for your veth (ethtool -K <iface>)?<br>
TL;DR recently, I have experienced that switching off TCP offloading<br>
for a veth (that I don't think it should have an effect) produced<br>
better throughput :/<br>
<br>
After you can check this things, we will be much smarter ;)<br>
<br>
Cheers,<br>
Levi<br>
<br>
On Wed, 2020-01-08 at 00:52 +0200, Matan Rosenberg wrote:<br>
> Running oproto/trace unfortunately does not explain why OVS chose to<br>
> look at these fields. <br>
> Using the same setup, for example:<br>
> <br>
> #  ovs-appctl ofproto/trace br0 in_port=a-<br>
> blue,dl_src=11:22:33:44:55:66,dl_dst=aa:bb:cc:dd:ee:ff,ipv4,nw_src=1.<br>
> 2.3.4<br>
> Flow:<br>
> ip,in_port=4,vlan_tci=0x0000,dl_src=11:22:33:44:55:66,dl_dst=aa:bb:cc<br>
> :dd:ee:ff,nw_src=1.2.3.4,nw_dst=0.0.0.0,nw_proto=0,nw_tos=0,nw_ecn=0,<br>
> 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>
> <br>
> It seems that the OpenFlow rule (not to be confused with the megaflow<br>
> entry) was correctly identified, and no other actions take place. <br>
> Since the relevant OpenFlow rule has nothing to do with the IP layer,<br>
> I don't understand why the megaflow is aware of it.<br>
> <br>
> I'll try to look at the classifier/megaflow code (?) tomorrow, but<br>
> I'd like to know if there's a high-level way to avoid such trouble.<br>
> <br>
> Thanks<br>
> <br>
> On Wed, 8 Jan 2020 at 00:39, Ben Pfaff <<a href="mailto:blp@ovn.org" target="_blank">blp@ovn.org</a>> wrote:<br>
> > 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<br>
> > don't need<br>
> > > OVS to look at other protocols beyond the Ethernet layer.<br>
> > > Additionally, we use VXLAN to establish L2 overlay networks<br>
> > across multiple<br>
> > > OVS servers.<br>
> > > <br>
> > > Just to make thing clear, these are some typical flow rules that<br>
> > 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<br>
> > use case,<br>
> > > it cannot handle more than couple thousand packets/s.<br>
> > > After some exploring, I've noticed that the installed megaflows<br>
> > try to<br>
> > > match on fields that are not present in the rules, apparently for<br>
> > 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<br>
> > random<br>
> > > addresses) to one of the red interfaces (with <br>
> > <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,<br>
> > bytes:2268,<br>
> > > used:1.337s, actions:3<br>
> > > recirc_id(0),in_port(2),eth(),eth_type(0x86dd),ipv6(frag=no),<br>
> > 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),<br>
> > 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<br>
> > relevant OpenFlow<br>
> > > rule to three separate megaflows, one for each eth_type (and even<br>
> > other<br>
> > > fields - IP fragmentation?).<br>
> > > In my production scenario, the packets are even more diversified,<br>
> > and we<br>
> > > see OVS installing flows which match on even more fields,<br>
> > including<br>
> > > specific Ethernet and IP addresses.<br>
> > > <br>
> > > This leads to a large number of flows that have extremely low hit<br>
> > rate -<br>
> > > each flow handles not more than ~100 packets (!) during its<br>
> > 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<br>
> > over the<br>
> > > place, or<br>
> > > 2) The huge number of inefficient megaflows leads to terrible<br>
> > lookup times<br>
> > > in the in-kernel megaflow table itslef (due to large number of<br>
> > masks, etc.)<br>
> > > <br>
> > > In short: how can I just make OVS oblivious to these fields? Why<br>
> > 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<br>
> > why OVS<br>
> > is matching on more fields than you expect.<br>
> <br>
> _______________________________________________<br>
> discuss mailing list<br>
> <a href="mailto:discuss@openvswitch.org" target="_blank">discuss@openvswitch.org</a><br>
> <a href="https://mail.openvswitch.org/mailman/listinfo/ovs-discuss" rel="noreferrer" target="_blank">https://mail.openvswitch.org/mailman/listinfo/ovs-discuss</a><br>
<br>
</blockquote></div>