WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Limits on mtu size ?

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Limits on mtu size ?
From: Hans de Bruin <jmdebruin@xxxxxxxxx>
Date: Fri, 07 Oct 2011 20:05:21 +0200
Delivery-date: Fri, 07 Oct 2011 11:09:28 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110903 Thunderbird/3.1.13

Network performance on fast physical networks usually increase by switching to larger packet sizes. So I decided to increase the mtu on my virtual networks to see if that has a positive effect. Anoyingly the bridge code does not allow you to increase the mtu above 1500 if no interface is attached to the bridge. Google tels me admins attach a nic to the bridge, increase the mtu and then remove the nic from the bridge as a work around. Then I noticed that the loopback has a whopping 16k mtu. For some reason adding lo to a bridge is not allowed. To shortcut workarounds and have fun with the mtu size I modified linux-2.6/net/bridge/br_if.c. There is a line: mtu = ETH_DATA_LEN; which I changed in to mtu = 16436; If lo can handle that size why not a bridge. So my setup now has two brides with oversized mtu's and one normal sized bidge to talk to my lan. This setup has run for two day's and now it suddenly broke while ssh/rsync-ing data between the to internal networks. A server called darkstar ran out of memory, as far as i can see with an empty swapfile, a server called orion, which was reseaving the data, stopped responding. Dom0 feels sluggish. So 16436 is to big and 9000 is not?

I have attached the complaints of darkstar. Its running out of kernel memory?

--
Hans

orion: 2 cpu, 1GB
darkstar: 2 cpu 512MB
...
dom0: 1 cpu's (dual core dual threaded), 1GB
kernels 3.1-rc7 and higher
xen 4.1.1
al pure pv.



Attachment: log.bz2
Description: Binary data

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>