From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 00/10] PV-IO v3 Date: Tue, 21 Aug 2007 15:25:48 +0300 Message-ID: <46CAD9CC.6050209@qumranet.com> References: <20070816231357.8044.55943.stgit@ghaskins-t60p.haskins.net> <1187313953.6449.70.camel@localhost.localdomain> <1187328402.4363.110.camel@ghaskins-t60p.haskins.net> <1187336618.6449.106.camel@localhost.localdomain> <1187358614.4363.135.camel@ghaskins-t60p.haskins.net> <1187652496.19435.141.camel@localhost.localdomain> <64F9B87B6B770947A9F8391472E032160D464FEB@ehost011-8.exch011.intermedia.net> <1187683122.19435.171.camel@localhost.localdomain> <1187697638.4363.277.camel@ghaskins-t60p.haskins.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, virtualization To: Gregory Haskins Return-path: In-Reply-To: <1187697638.4363.277.camel-5CR4LY5GPkvLDviKLk5550HKjMygAv58XqFh9Ls21Oc@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.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/