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: <41b516cb0608031334s6e159e99tb749240f44ae608d@mail.gmail.com>
Date:	Thu, 3 Aug 2006 13:34:12 -0700
From:	"Chris Leech" <chris.leech@...il.com>
To:	"Arnd Hannemann" <arnd@...dnet.de>
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

On 8/3/06, Arnd Hannemann <arnd@...dnet.de> wrote:
> 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?

Yes, e1000 devices will spill over and use multiple buffers for a
single frame.  We've been trying to find a good way to use multiple
buffers to take care of these allocation problems.  The structure of
the sk_buff does not make it easy.  Or should I say that it's the
limitation that drivers are not allowed to chain together multiple
sk_buffs to represent a single frame that does not make it easy.

PCI-Express e1000 devices support a feature called header split, where
the protocol headers go into a different buffer from the payload.  We
use that today to put headers into the kmalloc() allocated skb->data
area, and payload into one or more skb->frags[] pages.  You don't ever
have multiple page allocations from the driver in this mode.

We could try and only use page allocations for older e1000 devices,
putting headers and payload into skb->frags and copying the headers
out into the skb->data area as needed for processing.  That would do
away with large allocations, but in Jesse's experiments calling
alloc_page() is slower than kmalloc(), so there can actually be a
performance hit from trying to use page allocations all the time.

It's an interesting problem.

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