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
GFP_ATOMIC.
Oh.
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
pooling.
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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:23 EST