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: <20060804062008.GC413@2ka.mipt.ru>
Date:	Fri, 4 Aug 2006 10:20:08 +0400
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Chris Leech <chris.leech@...il.com>
Cc:	Krzysztof Oledzki <olel@....pl>, Arnd Hannemann <arnd@...dnet.de>,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: problems with e1000 and jumboframes

On Thu, Aug 03, 2006 at 01:32:10PM -0700, Chris Leech (chris.leech@...il.com) wrote:
> >Maximum e1000 frame is 16128 bytes, which is enough before being rounded
> >to 16k to have a space for shared info.
> >My patch just tricks refilling logic to request to allocate slightly less
> >than was setup when mtu was changed.
> 
> The maximum supported MTU size differs between e1000 devices due to
> differences in FIFO size.  For performance reasons the driver won't
> enable a MTU that doesn't allow for at least two frames in the Tx FIFO
> at once - you really want e1000 to be able to DMA the next frame into
> Tx FIFO while the current one is going out on the wire.  This doesn't
> change the fact that with LPE set, anything that can fit into the Rx
> FIFO and has a valid CRC will be DMAed into buffers regardless of
> length.

But still it must be less than MAX_JUMBO_FRAME_SIZE, which is 16128
bytes, at least it is maxiumum allowed mtu in e1000_change_mtu().

> >Hardware is not affected, second patch just checks if there is enough
> >space (e1000 stores real mtu). I can not believe that such modern NIC
> >like e1000 can not know in receive interrupt size of the received
> >packet, if it is true, than in generel you are right and some more
> >clever mechanisms shoud be used (at least turn hack off for small
> >packets and only enable it for less than 16 jumbo frames wheere place
> >always is), if size of the received packet is known, then it is enough
> >to compare aligned size and size of the packet to make a decision for
> >allocation.
> 
> You're changing the size of the buffer without telling the hardware.
> In the interrupt context e1000 knows the size of what was DMAed into
> the skb, but that's after the fact.  So e1000 could detect that memory
> was corrupted, but not prevent it if you don't give it power of 2
> buffers.  Actually, the power of 2 thing doesn't hold true for all
> e1000 devices.  Some have 1k granularity, but not Arnd's 82540.

I can not change it - code checks if requested mtu and additional size
is less than allocated aligned buffer it tricks allocator.
Or do you mean that even after 9k mtu was setup it is possible that card
can receive packets up to 16k?

> You can't know the size of a received packet before it's DMAed into
> host memory, no high performance network controller works that way.

> - Chris

-- 
	Evgeniy Polyakov
-
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/