lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5522D2B7.2050502@redhat.com>
Date:	Mon, 06 Apr 2015 11:38:47 -0700
From:	Alexander Duyck <alexander.h.duyck@...hat.com>
To:	Michael Cronenworth <mike@...tml.com>, netdev@...r.kernel.org
CC:	intel-wired-lan@...ts.osuosl.org
Subject: Re: e1000e max frame calculation


On 04/06/2015 09:38 AM, Michael Cronenworth wrote:
> Hello,
>
> I have attempted to discuss this with upstream directly[1], but they 
> will not respond to me. I will now attempt here.
>
> The e1000e driver uses a different maximum frame calculation after a 
> commit[2] in kernel 3.15. This caused everyone's setups that were 
> using 9000 for MTU to break after they rebooted on their kernel 
> update. The addition of the VLAN bytes force users to use 8996.
>
> Other drivers appear to be using the "old" maximum frame calculation 
> and can continue to use 9000.
>
> Can a standard be decided upon that all drivers use or is it 
> acceptable that one driver "does its own thing?"
>
> Thanks,
> Michael

What do you mean by "does its own thing"?  The problem here (I'm 
assuming, please correct me if I am wrong) is that the e1000e hardware 
is configured with a maximum frame size of 9018 based on the 
max_hw_frame_size value reported in the e1000_info struct for your 
part.  As a result you are limited to 8996 since it is forced to 
guarantee there is enough room for 1 VLAN header (4 bytes), the Ethernet 
header (14 bytes), and a CRC (4 bytes).  What you would need to 
determine is the reason why the hardware is limited to 9018, and not 
something like 9216 (9K) which is the more common value since it is 
rounded of to the nearest 1K.

Every piece of hardware will do things differently.  Within just the 
e1000e driver there are some parts that don't support jumbo frames, and 
some that only support 4K jumbo frames.  What would need to be 
determined is if 9018 is the actual limit on the hardware due to some 
limitation in the part, or if it was just an arbitrary value that was 
added by a developer so that it would come out at 9000 for a limit when 
changing the MTU.

- Alex
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ