linux-kernel - Re: problems with e1000 and jumboframes

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: <44D22350.5070709@arndnet.de>
Date:	Thu, 03 Aug 2006 18:24:48 +0200
From:	Arnd Hannemann <arnd@...dnet.de>
To:	Chris Leech <chris.leech@...il.com>
Cc:	Evgeniy Polyakov <johnpol@....mipt.ru>,
	Krzysztof Oledzki <olel@....pl>, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: problems with e1000 and jumboframes

Chris Leech schrieb:
> On 8/3/06, Evgeniy Polyakov <johnpol@....mipt.ru> wrote:
> 
>> > Strange, why this skb_shared_info cannon be added before first
>> alignment?
>> > And what about smaller frames like 1500, does this driver behave
>> similar
>> > (first align then add)?
>>
>> It can be.
>> Could attached  (completely untested) patch help?
> 
> Note that e1000 uses power of two buffers because that's what the
> hardware supports.  Also, there's no program able MTU - only a single
> bit for "long packet enable" that disables frame length checks when
> using jumbo frames.  That means that if you tell the e1000 it has a
> 16k buffer, and a 16k frame shows up on the wire, it's going to write
> to the entire 16k regardless of your 9k MTU setting.  If a 32k frame
> shows up, two full 16k buffers get written to (OK, assuming the frame
> can fit into the receive FIFO)
> 
> That's why I've always been against trying to optimize the allocation
> sizes in the driver, even with your small change the skb_shinfo area
> can get corrupted.  It may be unlikely, because the frame still has to
> be valid, but some switches aren't real picky about what sized frame
> they'll forward on if you enable jumbo support either.  So any box on
> the LAN could send you larger than MTU frames in an attempt to corrupt
> memory.
> 
> I believe that if you tell a hardware device it has a buffer of a
> certain size, you need to be prepared for that entire buffer to get
> written to.  Unfortunately that means wasteful allocations for e1000
> if a single buffer per frame is going to be used.

Well you say "if a single buffer per frame is going to be used". Well,
if I understood you correctly i could set the MTU to, lets say 4000.
Then the driver would enable the "jumbo frame bit" of the hardware, and
allocate only a 4k rx buffer, right? (and allocate 16k, because of
skb_shinfo)
Now if a new 9k frame arrives the hardware will accept it regardless of
the 2k MTU and will split it into 3x 4k rx buffers?
Does the current driver work in this way? That would be great.

Perhaps then one should change the driver in a way that the MTU can
changed independently of the buffer size?

> - Chris
> -

Thanks,
Arnd Hannemann.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/