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

[Seth Forshee]

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)

<snip>

>  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):

 e84f31d24fa5c099bb48590c7714bc9dba9c08fc
 04db90d2c4254941fb50d4d63b88ab7b06b7cd5f
 89110d95423b39a3e85f9a397c70afcb4c88f544
 6426a881fe5b176516bd579b2969e57438cfc154
 d37117d2f412885a149638c5b4211c92e1a78609

Seth