Messages in this thread | | | Date | Wed, 27 Sep 2023 11:10:50 +0300 | Subject | Re: [PATCH] bridge: MTU auto tuning ignores IFLA_MTU on NEWLINK | From | Nikolay Aleksandrov <> |
| |
On 9/27/23 10:57, Trent Lloyd wrote: > Commit 804b854d374e ("net: bridge: disable bridge MTU auto tuning if it > was set manually") disabled auto-tuning of the bridge MTU when the MTU > was explicitly set by the user, however that would only happen when the > MTU was set after creation. This commit ensures auto-tuning is also > disabled when the MTU is set during bridge creation. > > Currently when the br_netdev_ops br_change_mtu function is called, the > flag BROPT_MTU_SET_BY_USER is set. However this function is only called > when the MTU is changed after interface creation and is not called if > the MTU is specified during creation with IFLA_MTU (br_dev_newlink). > > br_change_mtu also does not get called if the MTU is set to the same > value it currently has, which makes it difficult to work around this > issue (especially for the default MTU of 1500) as you have to first > change the MTU to some other value and then back to the desired value. >
Yep, I think I also described this in the commit message of my patch.
> Add new selftests to ensure the bridge MTU is handled correctly: > - Bridge created with user-specified MTU (1500) > - Bridge created with user-specified MTU (2000) > - Bridge created without user-specified MTU > - Bridge created with user-specified MTU set after creation (2000) > > Regression risk: Any workload which erroneously specified an MTU during > creation but accidentally relied upon auto-tuning to a different value > may be broken by this change. >
Hmm, you're right. There's a risk of regression. Also it acts differently when set to 1500 as you've mentioned. I think they should act the same, also bridge's fake rtable RTAX_MTU is not set.
> Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2034099 > Fixes: 804b854d374e ("net: bridge: disable bridge MTU auto tuning if it was set manually") > Signed-off-by: Trent Lloyd <trent.lloyd@canonical.com> > ---
| |