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/
Home Products Support Community News


[Xen-users] xen bridge jumbo frame problems starting new DomU

To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-users] xen bridge jumbo frame problems starting new DomU
From: Fischer Udo Attila <udo@xxxxxx>
Date: Mon, 26 Oct 2009 12:40:25 +0100
Delivery-date: Mon, 26 Oct 2009 04:43:50 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (Windows/20090812)
Hi all,

My problem is using jumbo frames in vm-s using networking via bridge:

Facts I discovered:
- bridge will set automatically his mtu to the lowest interface MTU
- MTU can only set to max 1500 in the initialization phase of an DomU (via vif-bridge or vif common)
- MTU can only set higher some seconds after the DomU started

So the problem
I have to wait some seconds after I started a DomO and set manually
It sets the bridge back to MTU 1500 when the initialization script is running, affecting all DomUs using this bridge!!! It is not acceptable I think!

So I have a workaround:
I have created an additional bridge
set it in the DomU config and a vifname for the interface for easier scripting
start the DomU
sleep 5
brctl delif br2 xxx #where br2 is the additional bridge
ifconfig xxx mtu 9000
brctl addif br1 xxx #where br1 is the right one
So the problem is here not having network in the DomU for 5 seconds... (The smalles time was 2 seconds, but 5 for safety.. Ok I can write a script tries till its succeed.)

It is a very dirty solution....

Is there any other solution?
Is there any patch witch removes the 1500 MTU limit in the driver for the initialization phase, or a type=xxxx that allowes setting it higher?

Is there any solution planned to remove this behavior in the future? I think using Jumbo Frames is now everyday requirement to lower CPU IO utilization by Gigabit networks.

So the main point is, the bridge should not change the MTU downto 1500 by starting a new DomU affecting existing DomUs...

Other question:
Is there any patch that change the bridge behavior to the following way:
try to set the interface to the bridge MTU
if it fails it goes down in MTU till it works, and than set all other interfaces and the bridge down to this MTU... It not solves the first problem (init phase may 1500 MTU), but would be remove the problem by adding a new interface without increased MTU)

Best regards,
Udo Attila Fischer

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Xen-users mailing list
<Prev in Thread] Current Thread [Next in Thread>