[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [sneak preview] major scsi overhaul

From: Paul Brook
Subject: Re: [Qemu-devel] [sneak preview] major scsi overhaul
Date: Wed, 11 Nov 2009 04:06:31 +0000
User-agent: KMail/1.12.2 (Linux/2.6.30-2-amd64; KDE/4.3.2; x86_64; ; )

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 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]