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/ _______________________________________________ kvm-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/kvm-devel
