Messages in this thread |  | | Date | Thu, 14 Sep 2000 23:59:32 +1100 | From | Andrew Morton <> |
| |
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/
|  |