On Thu, Dec 04, 2008 at 04:07:04PM -0200, Eduardo Habkost wrote:
On Thu, Dec 04, 2008 at 05:54:24PM +0000, Mark McLoughlin wrote:
> On Thu, 2008-12-04 at 15:42 -0200, Eduardo Habkost wrote:
>
> > This implementation has an issue: it works when trying to set the MTU
> > below 1500, but the kernel bridge code doesn't let us to set the bridge
> > MTU above 1500 if there is no interface attached to the bridge yet. To
> > allow setting the bridge MTU higher than 1500, we need to save the
> > configured value somewhere and set it only when attaching tap interface
> > to it.
>
> Wait, that doesn't make much sense.
>
> 1) create bridge, can't set the MTU to greater than 1500
>
> 2) add tap device, set tap MTU to that of the bridge, i.e. 1500
On this case, the code would need to set the tap MTU to the one specified
on the configuration, not the one that the kernel has set on the bridge.
>
> 3) now setting the bridge MTU to >1500 won't work because it's greater
> that the MTU of one of the constituents
>
> Sounds to me like it's just a kernel bug - br_change_mtu() should allow
> an MTU of >ETH_DATA_LEN if the list is empty.
I am seeing this as an feature of the kernel bridging code that we would
need to handle. An annoying feature we could ask to be changed on the
kernel code, but something that libvirt could handle gracefully in case
the user is using an older kernel.
IMHO, fix the kernel and anyone that cares enough about this on older
kernels can backport the patch. The virtual network capability is primarily
targetted to people using desktop/laptop virt / wifi users, rather than
servers, so ability set large MTUs is not mission critical. Those users
are much more likely to be on latest kernel anyway
Daniel
--
|: Red Hat, Engineering, London -o-
http://people.redhat.com/berrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org -o-
http://ovirt.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|