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
| ||
|
Date: Wed, 08 Apr 2015 18:19:05 -0700 From: Alexander Duyck <alexander.duyck@...il.com> To: Hisashi T Fujinaka <htodd@...fifty.com> CC: Alexander Duyck <alexander.h.duyck@...hat.com>, intel-wired-lan@...ts.osuosl.org, jeffrey.t.kirsher@...el.com, netdev@...r.kernel.org, mike@...tml.com, david.m.ertman@...el.com Subject: Re: [PATCH] e1000e: Cleanup handling of VLAN_HLEN as a part of max frame size On 04/08/2015 05:26 PM, Hisashi T Fujinaka wrote: > On Wed, 8 Apr 2015, Hisashi T Fujinaka wrote: > >> On Wed, 8 Apr 2015, Alexander Duyck wrote: >>> >>> It is but it isn't. If you look in e1000_change_mtu you will find the >>> node about "Jumbo frame workaround on 82579 and newer requires CRC be >>> stripped". With that being the case I'm wondering if the 9018 doesn't >>> include CRC but instead includes VLAN header. So as a result the >>> actual >>> hardware is processing frames that are 9022 in size, but the buffer >>> only >>> ever receives at most 9018 since the CRC is stripped. >>> >>> I suspect that is why the Windows driver has had no issues reporting >>> support for a size of 9014 (excluding VLAN and CRC) on these parts and >>> hasn't had any issues. >> >> I can only tell you what was told to me by Dave Ertman, which is that >> there is a hard hardware limit of 9018 bytes. I wouldn't know if we do >> have Windows issues because it's a completely different division and >> there's no reason for any of those issues to be routed to us. >> >> In fact, the problem with different max MTU across the drivers in Linux >> has only ever been reported by one user. >> >> I'm still looking for the HW documentation and would like Jeff to hold >> off until we find it. > > OK. So the data sheet states: > > LPE controls whether long packet reception is permitted. Hardware > discards long packets if LPE is 0. A long packet is one longer than 1522 > bytes. If LPE is 1, the maximum packet size that the device can receive > is 9018 bytes. Yeah, that is mostly clear except it doesn't indicate if that includes or excludes the CRC and/or VLAN header. All the documentation I can find seems to indicate it is likely skipping one or the other since it recommends setting any switches to support 9022 in order to account for both. > So if you're pre-stripping the CRC, then it will be less than 9018. Right so the argument is probably moot since you cannot enable jumbo frames unless CRC stripping is enabled. Ugh, but it looks like nothing prevents disabling CRC stripping once jumbo frames has been enabled. I'll patch that shortly. > I guess I'd like to hear what Dave thinks. The problem is this pre-dates when Dave Ertman started working on e1000e. All of this went into effect back during the introduction of 82579 and i217/i218 and the two patches from Bruce that reduced the size down to 9018 didn't specify where the number came from. I suspect it is the same data sheet we have been looking at which is a bit vague about what is included in that size. -- 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