From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KtIsY-0005cH-QK for qemu-devel@nongnu.org; Fri, 24 Oct 2008 05:22:46 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KtIsX-0005bQ-5Z for qemu-devel@nongnu.org; Fri, 24 Oct 2008 05:22:46 -0400 Received: from [199.232.76.173] (port=50497 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KtIsW-0005bL-Pg for qemu-devel@nongnu.org; Fri, 24 Oct 2008 05:22:44 -0400 Received: from bart.se.axis.com ([195.60.68.10]:39236) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KtIsW-0003uO-O0 for qemu-devel@nongnu.org; Fri, 24 Oct 2008 05:22:44 -0400 Received: from bart.se.axis.com (bart.se.axis.com [127.0.0.1]) by bart.se.axis.com (Postfix) with ESMTP id 654286415F for ; Fri, 24 Oct 2008 11:22:43 +0200 (CEST) Received: from axis.com (edgar.se.axis.com [10.93.151.1]) by bart.se.axis.com (Postfix) with ESMTP id 46F3564136 for ; Fri, 24 Oct 2008 11:22:43 +0200 (CEST) Date: Fri, 24 Oct 2008 11:22:43 +0200 From: "Edgar E. Iglesias" Subject: Re: [Qemu-devel] [PATCH][RFT] Make DMA timer driven Message-ID: <20081024092243.GA26209@edgar.se.axis.com> References: <1224797417-26044-1-git-send-email-aliguori@us.ibm.com> <20081023220453.GA15547@edgar.se.axis.com> <200810240013.50522.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200810240013.50522.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: "Edgar E. Iglesias" , Anthony Liguori , qemu-devel@nongnu.org On Fri, Oct 24, 2008 at 12:13:49AM +0100, Paul Brook wrote: > > You can find info regarding CRIS/ETRAX testing here: > > http://lists.gnu.org/archive/html/qemu-devel/2008-09/msg00279.html > > > > I tested the patch. It works but unfortunately DMA transfers to/from > > the ethernet block now seem to emulate very slowly. > > Is there a reason you're deferring the DMA transfers, rather than completing > them immediately? In most cases you want to do the DMA as soon as both ends > are ready, and there's no benefit artificially delaying things. Any delay is > entirely arbitrary, and won't work reliably. Hello, If you are refering to the etrax dma/ethernet, any delays are unintentional. I removed the poll based ethernet receive path, so that rx packets now go straight into the dma without waiting for DMA_run but unfortunately the timer based DMA_run still slows things down for etrax. I'll try to look at it more when I get a free time slot.. Thanks