[Yakkety][PULL] fix for unable to set MTU larger than 1500

Seth Forshee seth.forshee at canonical.com
Thu May 11 14:36:38 UTC 2017

On Fri, May 05, 2017 at 12:44:47AM +0800, Jesse Sung wrote:
> BugLink: https://launchpad.net/bugs/1679823
> There are two issues in this report.
> The first one is unable to set MTU larger than 1500 on some devices.
> Commit e84f31d (yakkety), "net: centralize net_device min/max MTU
> checking", introduced net_device.min_mtu and net_device.max_mtu.
> These values will be checked before net_device_ops.ndo_change_mtu().
> Then the second commit 04db90d (yakkety) set the default value of
> min_mtu to ETH_MIN_MTU(68) and max_mtu to ETH_DATA_LEN(1500), removed
> ndo_change_mtu() callback in some NIC drivers, and initialize
> min_mtu/max_mtu in each driver if it should be something different
> than the default values.
> Commits for other drivers are not included in yakkety, thus when one
> try to set an MTU larger than ETH_DATA_LEN, it fails.
> The second issue is it shows
> "Invalid MTU 9000 requested, hw max 68"
> instead of
> "Invalid MTU 9000 requested, hw max 1500".
> This is a typo in commit 04db90d and can be fixed by commit a0e65de.
> These commits touch a lot of network drivers, but the changes are quite
> trivial. So far we have positive test results for
> * e1000e: comment 34
> * bnx2x: comment 39
> * ixgbe: comment 40
> * Zerotier TAP interfaces: comment 45
> The following changes since commit 86e762828b7506f5b776106018d7a867c15a0a84:
>   nvme: Quirk APST off on "THNSF5256GPUK TOSHIBA" (2017-05-04 10:54:20 +0200)
> are available in the git repository at:
>   git://git.launchpad.net/~wenchien/+git/yakkety lp1679823
> for you to fetch changes up to 3bc189cd9cc5a351b822adbacf1ad3867ca5d90e:
>   team: use ETH_MAX_MTU as max mtu (2017-05-04 21:57:59 +0800)


>  202 files changed, 726 insertions(+), 1289 deletions(-)

The changes themselves aren't all that scary, but the sheer amount of
them is. The fact that several commits are bug fixes for "let's make
theoretically non-functional changes to a load of drivers" is
evidence that these things frequently go bad.

I wonder, did you try reverting all the mtu patches in that original
hyperv series? It looks to me like they were included for completeness
rather than for any functional change. Fwiw I was able to revert this
set of commits without difficulty, which looks to be the complete set
required (I didn't do any testing with them reverted though):



More information about the kernel-team mailing list