<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/4.8.5">
</HEAD>
<BODY>
Thanks, Rick looks like GRO was something we was missing in our setup.<BR>
<BR>
Here are some results form my tests<BR>
<BR>
iperf with GRO disabled on server side : 2,5-3Gbps<BR>
iperf with GRO enabled on server side : 3,5-4 Gbps (gro was enabled on eth0, br-eth0, br-storage)<BR>
<BR>
Additionally i used OVS VLAN splinters option "Enable OVS VLAN splinters hard trunks workaround" of fuel deployment<BR>
<BR>
iperf with GRO disabled using hw VLAN splinters and MTU 1,5k : ~5 Gbps<BR>
iperf with GRO disabled using hw VLAN splinters and MTU 9k : 9-10 Gbps<BR>
iperf with GRO enabled using hw VLAN splinters and MTU 1,5k : 9-10 Gbps<BR>
<BR>
Then i tested iperf between machines of 2 different configurations (with OVS VLAN splinters, and without it),<BR>
<BR>
default->OVS_VLAN_spliters (GRO disabled) : 2,5 Gbps<BR>
default->OVS_VLAN_spliters (GRO enabled) : 5 Gbps<BR>
<BR>
OVS_VLAN_spliters->default (GRO disabled) : 2,5-3 Gbps<BR>
OVS_VLAN_spliters->default (GRO enabled) : 5-10 Gbps<BR>
<BR>
This looks like OVS is not performing good enough in this setup for tagged vlans (our br-storage is running on tagged vlan)<BR>
<BR>
any commands?<BR>
<BR>
<BR>
Dnia 2015-01-21, śro o godzinie 08:47 -0800, Rick Jones pisze:
<BLOCKQUOTE TYPE=CITE>
<PRE>
On 01/21/2015 03:20 AM, Skamruk, Piotr wrote:
<FONT COLOR="#737373">> On Wed, 2015-01-21 at 10:53 +0000, Skamruk, Piotr wrote:</FONT>
<FONT COLOR="#737373">>> On Tue, 2015-01-20 at 17:41 +0100, Tomasz Napierala wrote:</FONT>
<FONT COLOR="#737373">>>> [...]</FONT>
<FONT COLOR="#737373">>>> How this was measured? VM to VM? Compute to compute?</FONT>
<FONT COLOR="#737373">>> [...]</FONT>
<FONT COLOR="#737373">>> Probably in ~30 minutes we also will have results on plain centos with</FONT>
<FONT COLOR="#737373">>> mirantis kernel, and on fuel deployed centos with plain centos kernel</FONT>
<FONT COLOR="#737373">>> (2.6.32 in both cases, but with different patchset subnumber).</FONT>
<FONT COLOR="#737373">></FONT>
<FONT COLOR="#737373">> OK, our test were done little badly. On plain centos iperf were runned</FONT>
<FONT COLOR="#737373">> directly on physical interfaces, but under fuel deployed nodes... We</FONT>
<FONT COLOR="#737373">> ware using br-storage interfaces, which in real are openvs based.</FONT>
<FONT COLOR="#737373">></FONT>
<FONT COLOR="#737373">> So this is not a kernel problem, but this is a single stream over ovs</FONT>
<FONT COLOR="#737373">> issue.</FONT>
<FONT COLOR="#737373">></FONT>
<FONT COLOR="#737373">> So we will investigate this further...</FONT>
<FONT COLOR="#737373">></FONT>
Not sure if iperf will emit it, but you might look at the bytes per
receive on the receiving end. Or you can hang a tcpdump off the
receiving interface (the br-storage I presume here) and see if you are
getting the likes of GRO - if you are getting GRO you will see "large"
TCP segments in the packet trace on the receiving side. You can do the
same with the physical interfaces for comparison.
2.5 to 3 Gbit/s "feels" rather like what one would get with 10 GbE in
the days before GRO/LRO.
happy benchmarking,
rick jones
<A HREF="http://www.netperf.org/">http://www.netperf.org/</A>
</PRE>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>