[PATCH] bridge: increase mtu to 64K

[PATCH] bridge: increase mtu to 64K

[Michael Braun]

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: Michael Braun <michael-dev@fami-braun.de>
Reported-by: Li RongQing <roy.qing.li@gmail.com>

--
If found https://patchwork.ozlabs.org/project/netdev/patch/1456133351-10292-1-git-send-email-roy.qing.li@gmail.com/
but I am missing any follow up. So here comes a refresh patch that
addresses the issue raised.
---
 net/bridge/br_if.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
index 4fe30b182ee7..f14e7d2329bd 100644
--- a/net/bridge/br_if.c
+++ b/net/bridge/br_if.c
@@ -496,7 +496,7 @@ static int br_mtu_min(const struct net_bridge *br)
 		if (!ret_mtu || ret_mtu > p->dev->mtu)
 			ret_mtu = p->dev->mtu;
 
-	return ret_mtu ? ret_mtu : ETH_DATA_LEN;
+	return ret_mtu ? ret_mtu : (64 * 1024);
 }
 
 void br_mtu_auto_adjust(struct net_bridge *br)
-- 
2.20.1

Re: [PATCH] bridge: increase mtu to 64K

[Nikolay Aleksandrov]

On 07/05/2020 13:32, Michael Braun wrote:
> 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.
> 

Hi Michael,
That isn't correct, have you tested with a recent kernel?
After:
commit 804b854d374e
Author: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date:   Fri Mar 30 13:46:19 2018 +0300

    net: bridge: disable bridge MTU auto tuning if it was set manually

You can set the bridge MTU to anything before adding ports.

E.g.:
$ ip l add br1 type bridge
$ ip l set br1 mtu 65000
$ ip l sh dev br1
12: br1: <BROADCAST,MULTICAST> mtu 65000 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether b6:ad:91:dc:5f:39 brd ff:ff:ff:ff:ff:ff

And a second one (ens17, ens18 with MTU 1500, br0 new with MTU 1500):
$ ip l set ens17 master br0
$ ip l set ens18 master br0
$ ip l set br0 mtu 65000
$ ip l sh dev br0
11: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether fe:ed:3f:df:94:1f brd ff:ff:ff:ff:ff:ff
$ ip l sh dev ens17
8: ens17: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:23:5f:13 brd ff:ff:ff:ff:ff:ff

 
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1399064
> 
> Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
> Reported-by: Li RongQing <roy.qing.li@gmail.com>
> 
> --
> If found https://patchwork.ozlabs.org/project/netdev/patch/1456133351-10292-1-git-send-email-roy.qing.li@gmail.com/
> but I am missing any follow up. So here comes a refresh patch that
> addresses the issue raised.
> ---
>  net/bridge/br_if.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
> index 4fe30b182ee7..f14e7d2329bd 100644
> --- a/net/bridge/br_if.c
> +++ b/net/bridge/br_if.c
> @@ -496,7 +496,7 @@ static int br_mtu_min(const struct net_bridge *br)
>  		if (!ret_mtu || ret_mtu > p->dev->mtu)
>  			ret_mtu = p->dev->mtu;
>  
> -	return ret_mtu ? ret_mtu : ETH_DATA_LEN;
> +	return ret_mtu ? ret_mtu : (64 * 1024);
>  }
>  
>  void br_mtu_auto_adjust(struct net_bridge *br)
> 
Please CC bridge maintainers on bridge patches.
Note that there's a mechanism in the bridge to disable auto-MTU tuning if the user *changes*
the MTU manually (it's important the MTU actually changes by the op). The auto-tuning has
been a constant headache.

The patch also has a problem - it sets the MTU over ETH_MAX_MTU (65535).

Cheers,
 Nik

Re: [PATCH] bridge: increase mtu to 64K

[michael-dev]

Am 07.05.2020 13:06, schrieb Nikolay Aleksandrov:
> That isn't correct, have you tested with a recent kernel?
> After:
> commit 804b854d374e
> Author: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
> Date:   Fri Mar 30 13:46:19 2018 +0300

Thanks for pointing out, I'm sorry my test kernel was too old.

Regards,
Michael