From: Alexander Duyck <alexander.duyck@gmail.com>
To: Hisashi T Fujinaka <htodd@twofifty.com>
Cc: Alexander Duyck <alexander.h.duyck@redhat.com>,
intel-wired-lan@lists.osuosl.org, jeffrey.t.kirsher@intel.com,
netdev@vger.kernel.org, mike@cchtml.com,
david.m.ertman@intel.com
Subject: Re: [PATCH] e1000e: Cleanup handling of VLAN_HLEN as a part of max frame size
Date: Wed, 08 Apr 2015 18:19:05 -0700 [thread overview]
Message-ID: <5525D389.3010700@gmail.com> (raw)
In-Reply-To: <alpine.NEB.2.11.1504081714400.3388@chris.i8u.org>
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.
next prev parent reply other threads:[~2015-04-09 1:19 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-06 16:38 e1000e max frame calculation Michael Cronenworth
2015-04-06 18:38 ` Alexander Duyck
2015-04-06 21:45 ` Michael Cronenworth
2015-04-06 23:17 ` Alexander Duyck
2015-04-07 3:47 ` Hisashi T Fujinaka
2015-04-08 17:17 ` Alexander Duyck
2015-04-08 17:25 ` Hisashi T Fujinaka
2015-04-08 21:02 ` [PATCH] e1000e: Cleanup handling of VLAN_HLEN as a part of max frame size Alexander Duyck
2015-04-08 21:15 ` Hisashi T Fujinaka
2015-04-08 22:58 ` Alexander Duyck
2015-04-08 23:05 ` Hisashi T Fujinaka
2015-04-08 23:13 ` Alexander Duyck
2015-04-09 0:10 ` Hisashi T Fujinaka
2015-04-09 0:26 ` Hisashi T Fujinaka
2015-04-09 1:19 ` Alexander Duyck [this message]
2015-04-09 6:17 ` [Intel-wired-lan] " Templeman, Chaim
2015-04-09 15:51 ` Alexander Duyck
2015-04-13 18:26 ` Templeman, Chaim
2015-04-09 0:01 ` Jeff Kirsher
2015-04-09 4:48 ` Michael Cronenworth
2015-04-21 2:38 ` [Intel-wired-lan] " Brown, Aaron F
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5525D389.3010700@gmail.com \
--to=alexander.duyck@gmail.com \
--cc=alexander.h.duyck@redhat.com \
--cc=david.m.ertman@intel.com \
--cc=htodd@twofifty.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jeffrey.t.kirsher@intel.com \
--cc=mike@cchtml.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).