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 53DBFC433F5 for ; Tue, 22 Feb 2022 07:31:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231251AbiBVHcQ (ORCPT ); Tue, 22 Feb 2022 02:32:16 -0500 Received: from gmail-smtp-in.l.google.com ([23.128.96.19]:34300 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229688AbiBVHcP (ORCPT ); Tue, 22 Feb 2022 02:32:15 -0500 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 88FCB26565; Mon, 21 Feb 2022 23:31:49 -0800 (PST) Received: from canpemm500006.china.huawei.com (unknown [172.30.72.57]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4K2rN53B6Pzbbfj; Tue, 22 Feb 2022 15:27:17 +0800 (CST) Received: from [10.174.179.200] (10.174.179.200) by canpemm500006.china.huawei.com (7.192.105.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Tue, 22 Feb 2022 15:31:46 +0800 Subject: Re: [PATCH net] net: vlan: allow vlan device MTU change follow real device from smaller to bigger To: Eric Dumazet CC: Herbert Xu , David Miller , Jakub Kicinski , netdev , Vasily Averin , Kees Cook , LKML References: <20220221124644.1146105-1-william.xuanziyang@huawei.com> <8248d662-8ea5-7937-6e34-5f1f8e19190f@huawei.com> From: "Ziyang Xuan (William)" Message-ID: <124e1c43-95a8-1aad-c781-b43eba09984a@huawei.com> Date: Tue, 22 Feb 2022 15:31:45 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.179.200] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To canpemm500006.china.huawei.com (7.192.105.130) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > On Mon, Feb 21, 2022 at 6:06 PM Ziyang Xuan (William) > wrote: >> >>> On Mon, Feb 21, 2022 at 07:43:18AM -0800, Eric Dumazet wrote: >>>> >>>> Herbert, do you recall why only a decrease was taken into consideration ? >>> >>> Because we shouldn't override administrative settings of the MTU >>> on the vlan device, unless we have to because of an MTU reduction >>> on the underlying device. >>> >>> Yes this is not perfect if the admin never set an MTU to start with >>> but as we don't have a way of telling whether the admin has or has >>> not changed the MTU setting, the safest course of action is to do >>> nothing in that case. >> If the admin has changed the vlan device MTU smaller than the underlying >> device MTU firstly, then changed the underlying device MTU smaller than >> the vlan device MTU secondly. The admin's configuration has been overridden. >> Can we consider that the admin's configuration for the vlan device MTU has >> been invalid and disappeared after the second change? I think so. > > The answer is no. > > Herbert is saying: > > ip link add link eth1 dev eth1.100 type vlan id 100 > ... > ip link set eth1.100 mtu 800 > .. > ip link set eth1 mtu 256 > ip link set eth1 mtu 1500 > > -> we do not want eth1.100 mtu being set back to 1500, this might > break applications, depending on old kernel feature. > Eventually, setting back to 800 seems ok. It seem that setting back to 800 more reasonable. We can record user setting MTU by interface ndo_change_mtu() in struct vlan_dev_priv. > > If you want this new feature, we need to record in eth1.100 device > that no admin ever changed the mtu, > as Herbert suggested. > > Then, it is okay to upgrade the vlan mtu (but still is a behavioral > change that _could_ break some scripts) > > Thank you. > . >