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
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
start the DomU
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...
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)
Udo Attila Fischer
Description: S/MIME Cryptographic Signature
Xen-users mailing list