Bug 1119014 - e1000e jumbo frames no longer work: 'Unsupported MTU setting'
e1000e jumbo frames no longer work: 'Unsupported MTU setting'
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: fedora-kernel-ethernet
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2014-07-13 00:20 EDT by Michael Cronenworth
Modified: 2015-10-07 12:49 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-24 11:45:48 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michael Cronenworth 2014-07-13 00:20:42 EDT
Description of problem:
Attempting to use an MTU > 8996 no longer works with kernel 3.15. If a larger MTU is asked the driver emits:

e1000e 0000:00:19.0 em1: Unsupported MTU setting

I have been using a 9000 MTU without issue in all prior kernel versions. Intel advertises jumbo frame support for this network PHY.


Version-Release number of selected component (if applicable):
kernel-3.15.4-200.fc20.x86_64


How reproducible: Always


Steps to Reproduce:
1. ifconfig em1 mtu 9000
2.
3.

Actual results:
SIOCSIFMTU: Invalid argument
dmesg: e1000e 0000:00:19.0 em1: Unsupported MTU setting

Expected results:
ifconfig reports MTU of 9000

Additional info:
Motherboard: P8Z77-I DELUXE
Network PHY: 82579V
Comment 1 Rob Sanders 2014-08-01 12:13:02 EDT
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
Comment 2 Michael Cronenworth 2014-09-22 23:45:05 EDT
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.
Comment 3 Michael Cronenworth 2014-09-29 17:24:25 EDT
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
Comment 4 Raman Gupta 2014-11-03 11:11:16 EST
+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
Comment 5 Michael Cronenworth 2014-11-03 11:42:49 EST
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
Comment 6 Jeremy Harris 2014-11-05 07:42:15 EST
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.
Comment 7 Michael Cronenworth 2014-11-05 09:28:20 EST
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.
Comment 8 Fedora Kernel Team 2015-02-24 11:24:14 EST
*********** 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.
Comment 9 Rob Sanders 2015-02-24 11:33:32 EST
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
Comment 10 Josh Boyer 2015-02-24 11:45:48 EST
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.
Comment 11 Michael Cronenworth 2015-02-24 11:49:58 EST
Josh, you read the upstream report incorrectly. I will open a new report.
Comment 12 Josh Boyer 2015-02-24 11:55:10 EST
(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.
Comment 13 Michael Cronenworth 2015-02-24 12:12:52 EST
(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.
Comment 14 Michael Cronenworth 2015-04-13 14:33:18 EDT
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
Comment 16 Rob Sanders 2015-08-17 11:14:29 EDT
It's been backported to 4.1.4 as well.
Comment 17 tbsky 2015-10-07 12:24:26 EDT
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?
Comment 18 Josh Boyer 2015-10-07 12:49:01 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.