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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > Network performance on fast physical networks usually increase by > switching to larger packet sizes. So I decided to increase the mtu onmy> virtual networks to see if that has a positive effect. Anoyingly thebridge code> does not allow you to increase the mtu above 1500 if no interface isattached> 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 reasonadding> lo to a bridge is not allowed. To shortcut workarounds and have funwith 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 thatsize> why not a bridge. So my setup now has two brides with oversized mtu''sand> one normal sized bidge to talk to my lan. This setup has run for twoday''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 cansee with> an empty swapfile, a server called orion, which was reseaving thedata,> stopped responding. Dom0 feels sluggish. So 16436 is to big and 9000is not?> > I have attached the complaints of darkstar. Its running out of kernel > memory? >If all the hosts are Linux and GSO is enabled, the machines should be exchanging 64K packets anyway, regardless of MTU. James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 10/08/2011 12:29 AM, James Harper wrote: >> >> Network performance on fast physical networks usually increase by >> switching to larger packet sizes. So I decided to increase the mtu on ... > Dom0 feels sluggish. This was a wrong dns setting. So 16436 is to big and 9000 > is not? >> >> I have attached the complaints of darkstar. Its running out of kernel >> memory? >> > > If all the hosts are Linux and GSO is enabled, the machines should be > exchanging 64K packets anyway, regardless of MTU. > I should have read this http://lwn.net/Articles/188489/ -- Hans _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel