From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Reese Faucette" Subject: Re: vif interface dropping 80% packets Date: Tue, 6 Feb 2007 14:52:48 -0800 Message-ID: <00b901c74a41$86ba3b70$58c31fac@bart> References: <086c01c74986$0e8fd120$58c31fac@bart><08CA2245AFCF444DB3AC415E47CC40AF71781F@G3W0072.americas.hpqcorp.net> <007101c74a20$cf49d600$58c31fac@bart> <08CA2245AFCF444DB3AC415E47CC40AF71789E@G3W0072.americas.hpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org > You are probably using jumbo packets for native, right? What is the MTU > when you get > 9.88 Gb/s? I was thinking MTU=1500 when I said unrealistic. Not sure why > you cannot > get higher MTU in Xen to work. I have not tried MTU > 1500 bytes in Xen > myself but > I believe Herbert Xu has done that successfully. ok, true - got me there. TCP test with native linux sending to dom0 and 1500 MTU is 9.1GB/s and 23% of 1 CPU used on receiver. > If you get larger MTU to work, keep in mind that in Xen there is an extra > data copy > to transfer the packet from dom0 to guest which will have a higher impact > on performance > for larger MTUs when compared to linux. of course - i don't expect there to be no impact, but the numbers i was getting with mtu=1500 were horrid, like 70Mb/s using netperf with TCP_SENDFILE. a slower sender actually resulted in better throughput due to fewer dropped packets. (e.g. using TCP_STREAM got 220Mb/s, better but still stinky) update: MTU=9000 does work, I had failed to set one of the vif interfaces - plenty of interfaces to change ;-) The performance is better with 9k MTU, as expected: TCP_STREAM and TCP_SENDFILE both get ~1.8Gb/s, xentop reports 87% utilization for dom0, so I guess that's about all I can expect without code changes. If I understand the Xen bridge network flow, though, it's a real bummer that > First off, try switching to 3.0.4 and use the included 2.6.16-xen kernel. I can try, but the issue i had before was that 2.6.16 did not have the ethernet driver I need for the main ethernet connection: 0000:06:00.1 Ethernet controller: Intel Corporation Enterprise Southbridge DPT LAN Copper (rev 01) It comes with 2.6.18, but not 2.6.16, and the driver does not compile under 2.6.16, so i was stuck with 2.6.18. before I spend a lot of time converting to 3.0.4, a couple of questions: 1) any reason to expect better perf on 3.0.4 ? 2) if yes, Will the patch "fedora-36252.patch" work on the 2.6.16 kernel included with 3.0.4, or have conflicts crept in? thanks! -reese