[PATCH][net-next][v2] bridge: allow the maximum mtu to 64k

From: Li RongQing <redacted>

A linux bridge always adopts the smallest MTU of the enslaved devices.
When no device are enslaved, it defaults to a MTU of 1500 and refuses to
use a larger one. This is problematic when using bridges enslaving only
virtual NICs (vnetX) like it's common with KVM guests.

Steps to reproduce the problem

1) sudo ip link add br-test0 type bridge # create an empty bridge
2) sudo ip link set br-test0 mtu 9000 # attempt to set MTU > 1500
3) ip link show dev br-test0 # confirm MTU

Here, 2) returns "RTNETLINK answers: Invalid argument". One (cumbersome)
way around this is:

4) sudo modprobe dummy
5) sudo ip link set dummy0 mtu 9000 master br-test0

Then the bridge's MTU can be changed from anywhere to 9000.

This is especially annoying for the virtualization case because the
KVM's tap driver will by default adopt the bridge's MTU on startup
making it impossible (without the workaround) to use a large MTU on the
guest VMs.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1399064

Signed-off-by: Li RongQing <redacted>
---
 net/bridge/br_if.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
index c367b3e..a2ed99d 100644
--- a/net/bridge/br_if.c
+++ b/net/bridge/br_if.c

@@ -390,7 +390,9 @@ int br_del_bridge(struct net *net, const char *name)
 	return ret;
 }
 
-/* MTU of the bridge pseudo-device: ETH_DATA_LEN or the minimum of the ports */
+/* MTU of the bridge pseudo-device: the maximum IP packet size
+ * or the minimum of the ports
+ */
 int br_min_mtu(const struct net_bridge *br)
 {
 	const struct net_bridge_port *p;

@@ -399,7 +401,7 @@ int br_min_mtu(const struct net_bridge *br)
 	ASSERT_RTNL();
 
 	if (list_empty(&br->port_list))
-		mtu = ETH_DATA_LEN;
+		mtu = 64 * 1024;
 	else {
 		list_for_each_entry(p, &br->port_list, list) {
 			if (!mtu  || p->dev->mtu < mtu)

-- 
2.1.4

From: roy.qing.li@gmail.com
Date: Tue, 23 Feb 2016 09:00:56 +0800

This is especially annoying for the virtualization case because the
KVM's tap driver will by default adopt the bridge's MTU on startup
making it impossible (without the workaround) to use a large MTU on the
guest VMs.

So if the TAP device adopts the bridge's MTU, and then a device is
enslaved to the bridge that has a "smaller than 64k" MTU, what
propagates that MTU change back to the TAP device?

I really want to understand how this is supposed to work.

On Tue, 23 Feb 2016 09:00:56 +0800
roy.qing.li@gmail.com wrote:

This is especially annoying for the virtualization case because the
KVM's tap driver will by default adopt the bridge's MTU on startup
making it impossible (without the workaround) to use a large MTU on the
guest VMs.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1399064

This use case looks like KVM misusing bridge MTU. I.e it should set TAP
MTU to what it wants then enslave it, not vice versa.

On Thu, Feb 25, 2016 at 5:44 AM, Stephen Hemminger
[off-list ref] wrote:

quoted

This is especially annoying for the virtualization case because the
KVM's tap driver will by default adopt the bridge's MTU on startup
making it impossible (without the workaround) to use a large MTU on the
guest VMs.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1399064

This use case looks like KVM misusing bridge MTU. I.e it should set TAP
MTU to what it wants then enslave it, not vice versa.

1. a use should be able to configure an empty bridge MTU to a higher
mtu than 1500

2. if first configure the tap MTU a higher value, other port is lower
value, the pmtu
will be used, it maybe lower performance.
the configuration process is written into libvirt, located in
virnetdevtap.c, of cause it can
be improved to fix this issue.
https://www.redhat.com/archives/libvir-list/2008-December/msg00083.html

-R

From: Li RongQing <redacted>
Date: Thu, 25 Feb 2016 09:50:41 +0800

On Thu, Feb 25, 2016 at 5:44 AM, Stephen Hemminger
[off-list ref] wrote:

quoted

quoted

This is especially annoying for the virtualization case because the
KVM's tap driver will by default adopt the bridge's MTU on startup
making it impossible (without the workaround) to use a large MTU on the
guest VMs.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1399064

This use case looks like KVM misusing bridge MTU. I.e it should set TAP
MTU to what it wants then enslave it, not vice versa.

1. a use should be able to configure an empty bridge MTU to a higher
mtu than 1500

2. if first configure the tap MTU a higher value, other port is lower
value, the pmtu
will be used, it maybe lower performance.
the configuration process is written into libvirt, located in
virnetdevtap.c, of cause it can
be improved to fix this issue.
https://www.redhat.com/archives/libvir-list/2008-December/msg00083.html

You are saying that it is possible to achieve the behavior the user wants
with the mechanisms provided, which means this patch isn't necessary.

And if I added the patch it would be of limited value, since proper software
would have to cope with the behavior of older kernels anyways.

I'm not applying this, sorry.