All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Cronenworth <mike@cchtml.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [PATCH] e1000e: Cleanup handling of VLAN_HLEN as a part of max frame size
Date: Wed, 08 Apr 2015 23:48:51 -0500	[thread overview]
Message-ID: <552604B3.9070204@cchtml.com> (raw)
In-Reply-To: <20150408204630.4643.37880.stgit@ahduyck-vm-fedora22>

On 04/08/2015 04:02 PM, Alexander Duyck wrote:
> When the VLAN_HLEN was added to the calculation for the maximum frame size
> there seems to have been a number of issues added to the driver.
>
> The first issue is that in some cases the maximum frame size for a device
> never really reached the actual maximum frame size as the VLAN header
> length was not included the calculation for that value.  As a result some
> parts only supported a maximum frame size of either 1496 in the case of
> parts that didn't support jumbo frames, and 8996 in the case of the parts
> that do.
>
> The second issue is the fact that there were several checks that weren't
> updated so as a result setting an MTU of 1500 was treated as enabling jumbo
> frames as the calculated value was 1522 instead of 1518.  I have addressed
> those by replacing ETH_FRAME_LEN with VLAN_ETH_FRAME_LEN where appropriate.
>
> The final issue was the fact that lowering the MTU below 1500 would cause
> the driver to allocate 2K buffers for the rings.  This is an old issue that
> was fixed several years ago in igb/ixgbe and I am addressing now by just
> replacing == with a <= so that we always just round up to 1522 for anything
> that isn't a jumbo frame.

Alex,

Thanks taking the time to work on a patch.

I have tested this patch in 4.0 on i218-v hardware and it is working. I see 9000 in 
tcpdump (tso/gso off) and my switch blocks packets if I set the max frame size to 
9017 down from 9018.

I also played with a VLAN real quick, and did not encounter any problems, but I 
don't normally use VLANs so it may need further testing.

Thanks,
Michael

WARNING: multiple messages have this Message-ID (diff)
From: Michael Cronenworth <mike@cchtml.com>
To: Alexander Duyck <alexander.h.duyck@redhat.com>,
	intel-wired-lan@lists.osuosl.org, jeffrey.t.kirsher@intel.com
Cc: netdev@vger.kernel.org, htodd@twofifty.com
Subject: Re: [PATCH] e1000e: Cleanup handling of VLAN_HLEN as a part of max frame size
Date: Wed, 08 Apr 2015 23:48:51 -0500	[thread overview]
Message-ID: <552604B3.9070204@cchtml.com> (raw)
In-Reply-To: <20150408204630.4643.37880.stgit@ahduyck-vm-fedora22>

On 04/08/2015 04:02 PM, Alexander Duyck wrote:
> When the VLAN_HLEN was added to the calculation for the maximum frame size
> there seems to have been a number of issues added to the driver.
>
> The first issue is that in some cases the maximum frame size for a device
> never really reached the actual maximum frame size as the VLAN header
> length was not included the calculation for that value.  As a result some
> parts only supported a maximum frame size of either 1496 in the case of
> parts that didn't support jumbo frames, and 8996 in the case of the parts
> that do.
>
> The second issue is the fact that there were several checks that weren't
> updated so as a result setting an MTU of 1500 was treated as enabling jumbo
> frames as the calculated value was 1522 instead of 1518.  I have addressed
> those by replacing ETH_FRAME_LEN with VLAN_ETH_FRAME_LEN where appropriate.
>
> The final issue was the fact that lowering the MTU below 1500 would cause
> the driver to allocate 2K buffers for the rings.  This is an old issue that
> was fixed several years ago in igb/ixgbe and I am addressing now by just
> replacing == with a <= so that we always just round up to 1522 for anything
> that isn't a jumbo frame.

Alex,

Thanks taking the time to work on a patch.

I have tested this patch in 4.0 on i218-v hardware and it is working. I see 9000 in 
tcpdump (tso/gso off) and my switch blocks packets if I set the max frame size to 
9017 down from 9018.

I also played with a VLAN real quick, and did not encounter any problems, but I 
don't normally use VLANs so it may need further testing.

Thanks,
Michael

  parent reply	other threads:[~2015-04-09  4:48 UTC|newest]

Thread overview: 36+ 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 ` [Intel-wired-lan] " Alexander Duyck
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           ` [Intel-wired-lan] [PATCH] e1000e: Cleanup handling of VLAN_HLEN as a part of max frame size Alexander Duyck
2015-04-08 21:02             ` Alexander Duyck
2015-04-08 21:15             ` [Intel-wired-lan] " Hisashi T Fujinaka
2015-04-08 21:15               ` Hisashi T Fujinaka
2015-04-08 22:58               ` [Intel-wired-lan] " Alexander Duyck
2015-04-08 22:58                 ` Alexander Duyck
2015-04-08 23:05                 ` [Intel-wired-lan] " Hisashi T Fujinaka
2015-04-08 23:05                   ` Hisashi T Fujinaka
2015-04-08 23:13                   ` [Intel-wired-lan] " Alexander Duyck
2015-04-08 23:13                     ` Alexander Duyck
2015-04-09  0:10                     ` [Intel-wired-lan] " Hisashi T Fujinaka
2015-04-09  0:10                       ` Hisashi T Fujinaka
2015-04-09  0:26                       ` [Intel-wired-lan] " Hisashi T Fujinaka
2015-04-09  0:26                         ` Hisashi T Fujinaka
2015-04-09  1:19                         ` [Intel-wired-lan] " Alexander Duyck
2015-04-09  1:19                           ` Alexander Duyck
2015-04-09  6:17                           ` [Intel-wired-lan] " Templeman, Chaim
2015-04-09  6:17                             ` Templeman, Chaim
2015-04-09 15:51                             ` Alexander Duyck
2015-04-09 15:51                               ` Alexander Duyck
2015-04-13 18:26                               ` Templeman, Chaim
2015-04-13 18:26                                 ` Templeman, Chaim
2015-04-09  0:01             ` Jeff Kirsher
2015-04-09  0:01               ` Jeff Kirsher
2015-04-09  4:48             ` Michael Cronenworth [this message]
2015-04-09  4:48               ` Michael Cronenworth
2015-04-21  2:38             ` [Intel-wired-lan] " Brown, Aaron F
2015-04-21  2:38               ` 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=552604B3.9070204@cchtml.com \
    --to=mike@cchtml.com \
    --cc=intel-wired-lan@osuosl.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.