From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N84Tg-0003PK-0d for qemu-devel@nongnu.org; Tue, 10 Nov 2009 23:06:40 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N84Tb-0003IQ-4x for qemu-devel@nongnu.org; Tue, 10 Nov 2009 23:06:39 -0500 Received: from [199.232.76.173] (port=33963 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N84Tb-0003IB-1L for qemu-devel@nongnu.org; Tue, 10 Nov 2009 23:06:35 -0500 Received: from mx20.gnu.org ([199.232.41.8]:2099) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N84Ta-0005ZZ-MA for qemu-devel@nongnu.org; Tue, 10 Nov 2009 23:06:34 -0500 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N84TZ-0002Bu-Lp for qemu-devel@nongnu.org; Tue, 10 Nov 2009 23:06:34 -0500 From: Paul Brook Subject: Re: [Qemu-devel] [sneak preview] major scsi overhaul Date: Wed, 11 Nov 2009 04:06:31 +0000 References: <4AF4ACA5.2090701@redhat.com> In-Reply-To: <4AF4ACA5.2090701@redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200911110406.31319.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Gerd Hoffmann On Friday 06 November 2009, Gerd Hoffmann wrote: > Hi, > > http://repo.or.cz/w/qemu/kraxel.git/shortlog/refs/heads/scsi.v6 > > What is in there? > (3) New interface for HBA <=> SCSIDevice interaction: > * building on the new SCSIRequest struct. > * the silly read_data/write_data ping-pong game is gone. > * support for scatter lists and zerocopy I/O is there. The "silly ping-pong game" is there for a reason. Your code assumes that the whole transfer will be completed in a single request. This is not true for any of the current HBAs. Expecting the HBA to cache the entire response is simply not acceptable. Remember that a single transfer can be very large (greater than available ram on the host). Even with a SG capable HBA, you can not assume all the data will be transferred in a single request. You should also consider how this interacts with command queueing. IIUC an Initiator (HBA) typically sends a tagged command, then disconnects from the target (disk). At some later time the target reconnects, and the initiator starts the DMA transfer. By my reading your code does not issue any IO requests until after the HBA starts transferring data. The only way to achieve this is for the target to pretend it has data available immediately, at which point the transfer stalls and we loose the opportunity for parallel command queueing. On a cosmetic level, you seem somewhat schizophrenic between _req_ and _request_. Paul