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

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

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


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/