From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A7BB9E810A8 for ; Wed, 27 Sep 2023 08:11:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230182AbjI0ILG (ORCPT ); Wed, 27 Sep 2023 04:11:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33058 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230189AbjI0IK7 (ORCPT ); Wed, 27 Sep 2023 04:10:59 -0400 Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2822E1AD for ; Wed, 27 Sep 2023 01:10:54 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-3231d67aff2so6935637f8f.0 for ; Wed, 27 Sep 2023 01:10:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blackwall-org.20230601.gappssmtp.com; s=20230601; t=1695802252; x=1696407052; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=NBmOuCvdW9NVL1Xq7Sds9uqW+w+rqXLS8qDFF1herE8=; b=wplplTF1qcvKMbJrwn1Up67yl4q8GxN9VnoEY272AHk86WK/sOU4wbRm4Y9FAogAoQ eImV/fbNYtpo2HL0K7yxzJyKyTPKeDaTCSCf4AQrkEzFyA2RuPy3u76vQ8fIfB8Z0Iuf /t5SQ3aQmPr61OTfAYiTa2RZQOs7+WJf8p+VfuMaIrVh6VglkS7o0pbKgUkjKz7+pjxL rmbL/QW49h5uqH2X8F3ooS6BuGhYhXvf/UmJaR0maQ99yYEFX0tM0csmjJkNSY58EKB6 RIXGd79Xxyp+k+NPsDDPZey3GRYQHx9/IRCUCUc8qxNFdAeh3POlzRgwQtOE9rRu6qYb CMNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695802252; x=1696407052; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=NBmOuCvdW9NVL1Xq7Sds9uqW+w+rqXLS8qDFF1herE8=; b=bMquJLS9uOiY7P4pezUtXdfYQaMkzAPhDlX0oPUvO811l/uhWmFPH7IYwn9Q4Zt1b5 +2XzggUap/+Z+nglFM9DMBoImKNBiljqYj6+G5MgnMywl5bdHrloa1hAr0EpU/ynmPWf 50kQu6GDyvDGR7zt9+KwBiLO0tLGRHvcoSUsVBnGRGelCOwmhwbulfJqEgyl0FQ4S7zJ bV8R4+rFdTfOQOcXijFSLpX4asZVXT00SlCt8ftnOHDC9MpGk33ZHUntdkX/M9Mdwv+t X9Bx41G1ILyBxWidhErABX4rit31g6hxq60jhExmQ+ZMbPhr9vHh7aH2Rk7Og7icnudi uHpA== X-Gm-Message-State: AOJu0YzoBP+LyMqkPvFPmEnL820r8CdXhvbHitxxf69uCARFRpI9Dvb0 Ts+ZDAsqcG4uyA8/XpmSsy6XqA== X-Google-Smtp-Source: AGHT+IEKTsuknU2uuQEZaxLZtK8OwodOqhENja8RJX6uJxZpy29yQQXcdMSM3cppVDtiu8cEn9yLww== X-Received: by 2002:adf:fe49:0:b0:314:350a:6912 with SMTP id m9-20020adffe49000000b00314350a6912mr1190372wrs.36.1695802252428; Wed, 27 Sep 2023 01:10:52 -0700 (PDT) Received: from [192.168.0.105] (haunt.prize.volia.net. [93.72.109.136]) by smtp.gmail.com with ESMTPSA id m16-20020a056000009000b0031c71693449sm16622619wrx.1.2023.09.27.01.10.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 Sep 2023 01:10:52 -0700 (PDT) Message-ID: <3dccacd8-4249-87f8-690c-6083374dc9d1@blackwall.org> Date: Wed, 27 Sep 2023 11:10:50 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [PATCH] bridge: MTU auto tuning ignores IFLA_MTU on NEWLINK Content-Language: en-US To: Trent Lloyd , Roopa Prabhu , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Shuah Khan Cc: linux-kernel@vger.kernel.org, bridge@lists.linux-foundation.org, netdev@vger.kernel.org, linux-kselftest@vger.kernel.org References: <20230927075713.1253681-1-trent.lloyd@canonical.com> From: Nikolay Aleksandrov In-Reply-To: <20230927075713.1253681-1-trent.lloyd@canonical.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > ---