On 12/05/2014 01:20 AM, Andy Whitcroft wrote:
> Which is calculated rather simplistically where there are no attached
> devices:
>
> int br_min_mtu(const struct net_bridge *br)
> {
> [...]
> if (list_empty(&br->port_list))
> mtu = ETH_DATA_LEN;
> [...]
>
> It is not entirely clear why we care to clamp the MTU artificially at
> this level, as we will reevaluate the mtu and lower it when we do add a
> new bridge port.
Thanks for diving in the code Andy. IMHO, having the MTU defaulting to
1500 for an empty bridge makes sense but one should be able to manually
set it to a higher MTU.
> All of that said, if the MTU was set on the KVM tap before it was added
> then the bridge MTU should follow that device, and that appears to be
> the expected use model from the way the code is written.
Indeed, if the tap's MTU was bigger when it was enslaved it would just
work. Currently it works the other way around: the tap adopts the
bridge's MTU [1]
Regards,
Simon
[1]: https://www.redhat.com/archives/libvir-
list/2008-December/msg00083.html
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1399064
Title:
bridges cannot have a mtu > 1500 by themselves
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1399064/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
