On Thu, Jan 12, 2012 at 05:13:42PM +1100, Benjamin Herrenschmidt wrote:

On Thu, 2012-01-12 at 07:29 +0200, Michael S. Tsirkin wrote:

quoted

On Thu, Jan 12, 2012 at 09:56:39AM +1100, Benjamin Herrenschmidt wrote:

quoted

I'd suggest doing a simple user space app that creates such a ring,
forks, and produce / consume. We can then run that through perf and
analyze the cache behaviour, maximum throughput, etc....

Cheers,
Ben.

Sure. You can also use my tools/virtio hack: this rebuilds virtio
ring code in userspace, has the advantage of reusing
actual kernel code, so it's up to date, has same barriers, etc.

Yes, Rusty mentioned it today :-)

We'll play around in the next couple of weeks. With LCA, I'm not sure
how much I'll get done next week but heh...

I'm curious to see if we can still have a one-size-fit-all between
unordered blk requests with large data/descriptor access ratio and
ordered network buffers with a much smaller one.

Cheers,
Ben.

network buffers aren't ordered when the backend is zero copy.
Another idea is to add different sized bufs in the RX ring,
and have the device use the size that fits best.
This can improve small packet memory utilization without
need for data copies, but it also means that
descriptors are completed out of order in -net.