[libvirt] Re: [PATCH] bridge: set MTU of tap iface to the same value of the bridge

[Mark McLoughlin]

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.