Messages in this thread | | | Date | Wed, 23 Feb 2022 17:34:48 +0100 | From | Guillaume Nault <> | Subject | Re: [PATCH net] net: vlan: allow vlan device MTU change follow real device from smaller to bigger |
| |
On Wed, Feb 23, 2022 at 07:17:36AM -0800, Stephen Hemminger wrote: > On Wed, 23 Feb 2022 12:26:18 +0100 > Guillaume Nault <gnault@redhat.com> wrote: > > > On Tue, Feb 22, 2022 at 03:28:15PM -0800, Jakub Kicinski wrote: > > > On Tue, 22 Feb 2022 11:37:33 +0100 Guillaume Nault wrote: > > > > 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). > > > > > > My $0.02 would be that if we want to make changes that require new uAPI > > > we should do it across uppers. > > > > Do you mean something like: > > > > ip link set dev eth0 vlan-mtu-policy <policy-name> > > > > that'd affect all existing (and future) vlans of eth0? > > > > Then I think that for non-ethernet devices, we should reject this > > option and skip it when dumping config. But yes, that's another > > possibility. > > > > I personnaly don't really mind, as long as we keep a clear behaviour. > > > > What I'd really like to avoid is something like: > > - By default it behaves this way. > > - If you modified the MTU it behaves in another way > > - But if you modified the MTU but later restored the > > original MTU, then you're back to the default behaviour > > (or not?), unless the MTU of the upper device was also > > changed meanwhile, in which case ... to be continued ... > > - BTW, you might not be able to tell how the VLAN's MTU is going to > > behave by simply looking at its configuration, because that also > > depends on past configurations. > > - Well, and if your kernel is older than xxx, then you always get the > > default behaviour. > > - ... and we might modify the heuristics again in the future to > > accomodate with situations or use cases we failed to consider. > > > > In general these kind of policy choices are done via sysctl knobs. > They aren't done at netlink/ip link level.
I don't really mind if the configuration is per vlan, per upper device or per netns, as long as we keep a clear behaviour by default.
| |