Messages in this thread | | | Subject | Re: [PATCH net] net: vlan: allow vlan device MTU change follow real device from smaller to bigger | From | "Ziyang Xuan (William)" <> | Date | Tue, 22 Feb 2022 15:31:45 +0800 |
| |
> 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.
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. > . >
| |