From: Nikolay Aleksandrov <razor@blackwall.org>
To: Trent Lloyd <trent.lloyd@canonical.com>,
Roopa Prabhu <roopa@nvidia.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Shuah Khan <shuah@kernel.org>
Cc: linux-kernel@vger.kernel.org, bridge@lists.linux-foundation.org,
netdev@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH] bridge: MTU auto tuning ignores IFLA_MTU on NEWLINK
Date: Wed, 27 Sep 2023 11:34:57 +0300 [thread overview]
Message-ID: <9ac9b0bf-88e9-5156-a01c-507ae331dd9e@blackwall.org> (raw)
In-Reply-To: <3dccacd8-4249-87f8-690c-6083374dc9d1@blackwall.org>
On 9/27/23 11:10, Nikolay Aleksandrov wrote:
> 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.
>
The last part about RTAX_MTU is probably a separate issue. :)
>> 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>
>> ---
>
next prev parent reply other threads:[~2023-09-27 8:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-27 7:57 [PATCH] bridge: MTU auto tuning ignores IFLA_MTU on NEWLINK Trent Lloyd
2023-09-27 8:10 ` Nikolay Aleksandrov
2023-09-27 8:34 ` Nikolay Aleksandrov [this message]
2023-09-28 12:35 ` Nikolay Aleksandrov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9ac9b0bf-88e9-5156-a01c-507ae331dd9e@blackwall.org \
--to=razor@blackwall.org \
--cc=bridge@lists.linux-foundation.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=roopa@nvidia.com \
--cc=shuah@kernel.org \
--cc=trent.lloyd@canonical.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).