Gregory Haskins wrote:
On Tue, 2007-08-21 at 17:58 +1000, Rusty Russell wrote:
Partly the horror of the code, but mainly because it is an in-order
ring. You'll note that we use a reply ring, so we don't need to know
how much the other side has consumed (and it needn't do so in order).
I have certainly been known to take a similar stance when looking at Xen
code ;) (recall the lapic work I did). However, that said I am not yet
convinced that an out-of-order ring (at least as a fundamental
primitive) buys us much.
It's pretty much required for block I/O into disk arrays.
Xen does out-of-order, btw, on its single ring, but at the cost of some
complexity. I don't believe it is worthwhile and prefer split
request/reply rings.
With my VJ T-shirt on, I can even say it's more efficient, as each side
of the ring will have a single writer and a single reader, reducing
ping-pong effects if the interrupt completions happens to land on the
wrong cpu.
I think the use of rings for the tx-path in of
itself is questionable unless you can implement something like the bidir
NAPI that I demonstrated in ioqnet. Otherwise, you end up having to
hypercall on each update to the ring anyway and you might as well
hypercall directly w/o using a ring.
Network tx can be out of order too (with some traffic destined to other
guests, some to the host, and some to external interfaces, completions
will be out of order).
--
error compiling committee.c: too many arguments to function
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization
