[Top] [All Lists]

Re: I need sk_buff frag_list info.

To: Andi Kleen <ak@xxxxxxx>
Subject: Re: I need sk_buff frag_list info.
From: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Fri, 22 Mar 2002 13:41:09 +0100
Cc: Donald Becker <becker@xxxxxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: <20020321174219.A26613@xxxxxxxxxxxxx>
References: <20020317105928.A15784@xxxxxxxxxxxxx> <Pine.LNX.4.33.0203181202500.967-100000@presario> <20020321174219.A26613@xxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
Andi Kleen writes:

 > I fully agree. I played with this a few years ago with slab
 > (you can still see the commented out skb_add_mtu() function in skbuff.c),
 > but it didn't help much with 4K pages. Now with 8K page sizes becomming
 > more common that changes of course.
 > The standard power of two spacing of the slab kmalloc is IMHO very stupid.
 > I think one of the later slab papers from Sun even noted that power of
 > two is the worst packing for many cases.
 > There must be surely a better list of values that would better for
 > many workloads (not for 1.5K ethernet on 4K, but for other things) 
 > 9k jumbo frames have the same problem unfortunately, you cannot pack
 > two into a 16K double page, which is always allocated. 


Here is an related experiment with e1000 allocating different slab-sizes
Originally e1000 allocates 4k slabs for ordinary 1500 MTU ethernet packets.

The e1000 driver was changed to use 2k as a comparison. 

The forwarding path was tested with 1 Million 64 byte packets @ 1 Mpps. 
Kernel 2.4.16/NAPI

/proc/slabinfo with orig driver
size-4096            524    526   4096  524  526    1
size-2048              8      8   2048    4    4    1

/proc/slabinfo with patch for 2k
size-4096             12     13   4096   12   13    1
size-2048            520    856   2048  263  428    1

   slab-   throughput 
   2k      34.3%
   4k      32.7%


<Prev in Thread] Current Thread [Next in Thread>