Messages in this thread | | | Date | Tue, 22 Feb 2022 11:37:33 +0100 | From | Guillaume Nault <> | Subject | Re: [PATCH net] net: vlan: allow vlan device MTU change follow real device from smaller to bigger |
| |
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. >
| |