netdev - Re: [PATCH] e1000e: Cleanup handling of VLAN

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]

Date:	Wed, 08 Apr 2015 23:48:51 -0500
From:	Michael Cronenworth <mike@...tml.com>
To:	Alexander Duyck <alexander.h.duyck@...hat.com>,
	intel-wired-lan@...ts.osuosl.org, jeffrey.t.kirsher@...el.com
CC:	netdev@...r.kernel.org, htodd@...fifty.com
Subject: Re: [PATCH] e1000e: Cleanup handling of VLAN_HLEN as a part of max
 frame size

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
--
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