Bug 1119014

Same problem here:

product: GRYPHON Z87
vendor: ASUSTeK COMPUTER INC.
version: Rev 1.xx

00:19.0 Ethernet controller [0200]: Intel Corporation Ethernet Connection I217-V [8086:153b] (rev 05)
        Subsystem: ASUSTeK Computer Inc. Device [1043:859f]
        Kernel driver in use: e1000e
        Kernel modules: e1000e

Still broken in the 3.16 kernel series. I've glanced at the e1000e commits but don't see anything that resembles a breakage with regards to jumbo frame support.

Upstream says the hardware has a limit of 8996, but previous kernels (appeared) to work at 9000 without any quality or performance issues. I'm asking for clarification.

http://sourceforge.net/p/e1000/bugs/431

+1

00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 05)
        Subsystem: ASUSTeK Computer Inc. P8P67 Deluxe Motherboard
        Kernel driver in use: e1000e
        Kernel modules: e1000e

FYI, I found this statement on the e1000 devel mailing list (http://sourceforge.net/p/e1000/mailman/message/32636360/):

> In regards to the max MTU setting: The hardware has a set limit on supported
> maximum frame size (9018), and with the addition of the VLAN_HLEN (4) in
> calculating the header size (now it is 22) , the max configurable MTU is now
> 8996.
> 
> Dave Ertman

Thanks for that comment.

I found that Red Hat introduced this change so it's appropriate that this bug report lives here.

The change is forcing everyone to eat the 4-byte VLAN header whether you use VLAN or not.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/net/ethernet/intel/e1000e/netdev.c?id=c751a3d58cf2dae89ec941a259025b0175d67b0c

The only other solution I see to the hardware frame size limitation would be
to cap the buffer size at the hardware limit, ETH_HLEN + 9000 + ETH_FCS_LEN (but
otherwise include VLAN_HLEN), accept up to 9000 MTU, and drop any outbound
packet which would exceed the buffer.  Presumably this would only occur with a
fullsize VLAN'd packet; we'd be lying about the MTU that the interface supported
for VLANs.

Double-tagged VLAN packets still seem like an issue.

Isn't that how a 1500 MTU is handled? People have to drop to 1496 if they have a VLAN and their hardware doesn't support a 1522 byte frame.

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs.

Fedora 20 has now been rebased to 3.18.7-100.fc20.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 21, and are still experiencing this issue, please change the version to Fedora 21.

If you experience different issues, please open a new bug report for those.

The issue is still present in Fedora 21

$ dmesg | grep e1000e
[    0.847920] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
[    0.847921] e1000e: Copyright(c) 1999 - 2014 Intel Corporation.
[    0.848040] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
[    0.848054] e1000e 0000:00:19.0: irq 29 for MSI/MSI-X
[    1.013022] e1000e 0000:00:19.0 eth0: registered PHC clock
[    1.013024] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) ac:22:0b:c9:d9:95
[    1.013025] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
[    1.013063] e1000e 0000:00:19.0 eth0: MAC: 11, PHY: 12, PBA No: FFFFFF-0FF
[    1.015228] e1000e 0000:00:19.0 em1: renamed from eth0
[   92.999108] e1000e 0000:00:19.0: irq 29 for MSI/MSI-X
[   93.099409] e1000e 0000:00:19.0: irq 29 for MSI/MSI-X
[   96.474916] e1000e: em1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
[  102.529844] e1000e 0000:00:19.0 em1: Unsupported MTU setting
[ 1693.693040] e1000e 0000:00:19.0 em1: Unsupported MTU setting
[ 3131.383052] e1000e 0000:00:19.0 em1: Unsupported MTU setting
[ 4653.417823] e1000e 0000:00:19.0 em1: Unsupported MTU setting
[ 6090.615922] e1000e 0000:00:19.0 em1: Unsupported MTU setting
[ 7495.749378] e1000e 0000:00:19.0 em1: Unsupported MTU setting
[ 8956.608270] e1000e 0000:00:19.0 em1: Unsupported MTU setting
[10413.513357] e1000e 0000:00:19.0 em1: Unsupported MTU setting
[11820.906289] e1000e 0000:00:19.0 em1: Unsupported MTU setting
[13380.168530] e1000e 0000:00:19.0 em1: Unsupported MTU setting
[14774.343403] e1000e 0000:00:19.0 em1: Unsupported MTU setting


$ uname -r
3.18.7-200.fc21.x86_64

The commit that introduced this change has been in the kernel for a bit shy of 1 year at this point.  The upstream Intel maintainer hasn't deviated from it.  The upstream sourceforge bug has been closed out by an Intel maintainer.

We aren't going to do anything in Fedora here.  If a change happens, it needs to happen upstream.

Josh, you read the upstream report incorrectly. I will open a new report.

(In reply to Michael Cronenworth from comment #11)
> Josh, you read the upstream report incorrectly. I will open a new report.

It is pretty hard to misread "Closed->Wontfix".  You can open a new report if you'd like, but from a Fedora standpoint this is still an upstream issue.

(In reply to Josh Boyer from comment #12)
> It is pretty hard to misread "Closed->Wontfix".

That's not what my comment meant. The upstream bug report was closed improperly.

For those visiting via Google or on the CC list upstream has developed a patch to correct the max MTU calculation. It is working its way into mainline.

http://www.spinics.net/lists/netdev/msg324439.html

It has finally hit mainline.

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/net/ethernet/intel/e1000e?id=8084b86dcfbc4b4822868c1dbdb429b5c08154e2

Will be released in 4.2.

It's been backported to 4.1.4 as well.

hi:
    I am using rhel 7.1 and I can only set MTU=8996 with e1000e driver. according to the discussion, this bug should only happen after kernel > 3.15. so I think rhel 7.1 was affected by backported driver? if so, will rhel 7.2 have corrected backported driver to fix the issue?

Please open a bug against the RHEL product for this issue.  The Fedora kernel maintainers are not aware of what is or is not included in the RHEL kernels.