[lkml]   [2000]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
jamal wrote:
> The FF code of the tulip does have skb recycling code.
> And i belive Jes' acenic code does or did at some point.

But this isn't preallocation. Unless you got cute, this scheme would
limit the "preallocation" to the DMA ring size.

For network-intensive applications, a larger pool of preallocated
buffers would allow a driver to handle Rx packet bursts more
gracefully. Make the pool size tunable to match the desired max burst
size, as well as to avoid davem's Oracle problem.

At present we perform the allocation at interrupt time which is
precisely when we shouldn't. A background kernel thread which keeps the
pool topped up would even things out and would give a significant
increase in our peak Rx rates, up to a particular burst size.

This is considerable smarter than simply tweaking the driver for huge
DMA ring sizes. It is pretty specialised though.

One big bonus: the packets can then be allocated GFP_KERNEL rather than


A quick measurement says dev_alloc_skb(1000) takes about 450 cycles
on x86. At 150 kpps that's a potential 10% loss from your peak
burst rate.

But for 3c59x (which is not a very efficient driver (yet)), it takes 6
usecs to even get into the ISR, and around 4 uSecs to traverse it.
Guess another 4 to leave the ISR, guess half as much again for whoever
got interrupted to undo the resulting cache pollution.

That's 20 usec per interrupt, of which 1 usec could be saved by skb

If you don't do Rx interrupt mitigation there's no point in event
thinking about skb pooling.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.072 / U:3.352 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site