Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 22 Feb 2022 11:37:33 +0100
From:   Guillaume Nault <gnault@redhat.com>
To:     Eric Dumazet <edumazet@google.com>
Cc:     "Ziyang Xuan (William)" <william.xuanziyang@huawei.com>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        David Miller <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        netdev <netdev@vger.kernel.org>,
        Vasily Averin <vvs@virtuozzo.com>,
        Kees Cook <keescook@chromium.org>,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net] net: vlan: allow vlan device MTU change follow real
 device from smaller to bigger
Message-ID: <20220222103733.GA3203@debian.home>
References: <20220221124644.1146105-1-william.xuanziyang@huawei.com>
 <CANn89iKyWWCbAdv8W26HwGpM9q5+6rrk9E-Lbd2aujFkD3GMaQ@mail.gmail.com>
 <YhQ1KrtpEr3TgCwA@gondor.apana.org.au>
 <8248d662-8ea5-7937-6e34-5f1f8e19190f@huawei.com>
 <CANn89iLf2ira4XponYV91cbvcdK76ekU7fDW93fmuJ3iytFHcw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CANn89iLf2ira4XponYV91cbvcdK76ekU7fDW93fmuJ3iytFHcw@mail.gmail.com>
Precedence: bulk

On Mon, Feb 21, 2022 at 06:27:46PM -0800, Eric Dumazet wrote:
> On Mon, Feb 21, 2022 at 6:06 PM Ziyang Xuan (William)
> <william.xuanziyang@huawei.com> 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.
> 
> 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)

What about an explicit option:

  ip link add link eth1 dev eth1.100 type vlan id 100 follow-parent-mtu


Or for something more future proof, an option that can accept several
policies:

  mtu-update <reduce-only,follow,...>

      reduce-only (default):
        update vlan's MTU only if the new MTU is smaller than the
        current one (current behaviour).

      follow:
        always follow the MTU of the parent device.

Then if anyone wants more complex policies:

      follow-if-not-modified:
        follow the MTU of the parent device as long as the VLAN's MTU
        was not manually changed. Otherwise only adjust the VLAN's MTU
        when the parent's one is set to a smaller value.

      follow-if-not-modified-but-not-quite:
        like follow-if-not-modified but revert back to the VLAN's
        last manually modified MTU, if any, whenever possible (that is,
        when the parent device's MTU is set back to a higher value).
        That probably requires the possibility to dump the last
        modified MTU, so the administrator can anticipate the
        consequences of modifying the parent device.

     yet-another-policy (because people have a lot of imagination):
       for example, keep the MTU 4 bytes lower than the parent device,
       to account for VLAN overhead.

Of course feel free to suggest better names and policies :).

This way, we can keep the current behaviour and avoid unexpected
heuristics that are difficult to explain (and even more difficult for
network admins to figure out on their own).

> Thank you.
>