I would like to open a discussion on this as it's likely to be a fairly complicated feature to do in what i believe to be the correct way.
I happen to need MTU's over 9000 on some interfaces, at the very least i would need 9050. Right now i am just manually overriding with ip link, but an actual solution is warranted i believe. I have switches that perform EBGP / hardware VXLAM vtep and they expect to be able to communicate with the host at it's native MTU. VXLANS add a 50 byte header to all packets, so to have 9000 MTU on a VXLAN interface, you need an MTU of at least 9050 on it's parent interface.
I'm sure there are other use cases for higher than 9000 MTU's, but beyond that size things get weird interface wise. There is no standard size for max MTU above 9000, some interfaces support 9.6K, 9.7K, 10K, 16K, etc... It all comes down to driver / hardware support.
Right now, interface MTU ranges are specified in XML files with fixed values. One solution is to just raise the cap to 9050 for this specific use case, but i believe the better solution is to grab the max / min MTU from the interface and use those values as caps.
an example of extracting max mtu from an interface...
ip -d link show dev <interface name> | sed -n -e 's/^.*maxmtu //p' | awk '{print $1}'
Considering these values are currently statically defined, adding this functionality would not be a simple fix. My initial idea is to scan the physical interfaces at boot, and store those values perhaps in /tmp where the configuration tool can grab them. Rebooting would keep these constantly updated with the current physical interfaces in the machine.
For non-physical interfaces such as dummy / vxlan you can keep the static assignment.
I would be interested in other peoples thoughts on how to address this?