Re: [PATCH 00/10] PV-IO v3

Avi Kivity
2007-08-21T12:25:48Z

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