On Tue, 2008-12-02 at 19:08 -0200, Eduardo Habkost wrote: > Hi, > > This is a follow-up to the RFC patch sent by Chris Wright, at: > https://www.redhat.com/archives/libvir-list/2008-November/msg00225.html > > With this patch, instead of hardcoding the MTU to an high value, we set > the MTU of the tap interface to the same MTU value set on the bridge > interface. The current code uses the default tap MTU value and lowers > the bridge interface MTU without any need, killing performance. > > I will send another patch later for allowing the tap MTU to be configured > on the XML, but the behavior added by this patch will be kept as the > default. The default behavior should be enough for most use cases where > a larger MTU is wanted for the bridged interfaces. Interesting twist :-) The bridge MTU is limited to the lowest MTU of its constituents. The tap MTU is pretty irrelevant when you connect it to a bridge, since no host tx packets will originate tap device ... so the only purpose in raising the tap MTU is raising the upper limit of the bridge MTU. So basically this patch is trying to take the tap MTU out of the equation when the tap device is enslaved to a bridge. However, consider this sequence: 1) Bridge br0 exists with a single interface (eth0) enslaved and the MTU of both is 1500 2) Start guest foo, and vnet0 is enslaved to br0 with an automatic MTU of 1500 3) User tries to up the MTU of eth0 to 9000, but is prevented from doing so because the bridge MTU is constrained by the MTU of vnet0 But it would work fine if you had increased the eth0 MTU *before* starting the guest. Does it make sense to automatically set the tap MTU to a very large value so as to ensure that the bridge MTU is only constrained by the MTU of the physical device? Well, no it doesn't because in the case of a virtual network there is no physical MTU so the bridge would end up with a large MTU and there's no guarantee qemu or the host can handle that. Conclusions from above meandering: 1) Your patch is a sensible default; not perfect, but a very good compromise 2) The next thing we need is a patch to allow changing setting the MTU for the bridge in a virtual network e.g. <network> <name>foo</name> <bridge name='virbr1'/> </network> 3) I don't think having a way in libvirt to configure the MTU of an enslaved TAP device is interesting given both of the above 4) I've added a tiny hint to: http://wiki.libvirt.org/page/Networking about configuring a physical device's MTU when setting it up a shared physical interface. HTH, Mark. -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list