[Stgt-devel] stgt & IBM virtual SCSI Target Driver
michaelc at cs.wisc.edu
Thu Sep 8 22:44:10 CEST 2005
FUJITA Tomonori wrote:
> In case of DMA_TO_DEVICE, your driver asks stgt to create a new
> command and allocate sg buffer, and then copy data from initiator's
> buffer. After that, it asks stgt to perform the command.
We need a way to set certain limits that exist with the request_queue
and initiator drivers so that target drivers can get a cmnd with a
scatterlist which they can pass to their HW or lowerlevel APIs they use.
Does vscsi use an API which can takes a scatter list mapped by one of
the dma_map_* functions? If so we need to add the correct limits onto
something so the cmnd buffer allocation code can allocate a buffer with
the correct number of segments.
This is the part I was mentioning in some other mail. Today sg and st
replicate a bunch of scatterlist code and I am trying to rip it out and
replace it with block layer code so there is less duplication. stgt
should hopefully be able to reuse this code.
> 1. Your driver uses bio to access non-scsi devices. I think that it
> leads to poor read performance. Why do you use the vfs interface to
> exploit page cache?
Also the scsi_request usage is bad for the scsi devices btw. We are
trying to kill that in linux-scsi. It was one thing that we would have
had to kill from scst.
> 2. About task attribute, you can support only simple and ordered. You
> implement 'ordered task' to use bio barrier. So you don't have a
> complete code to handle all task attributes?
> stgt interface needs to be changed to support task attribute
> feature. I also think that we can simplify stgt_cmnd_* and buffer
> allocation interfaces. In short, I don't think that target drivers
Maybe we clean up the interfaces but I think that the stgt code will
have to become more complicated. I think we are going to have to add to
them to support correct scatterlist allocations for HW targets at least.
Also I think there will be some HW targets which cannot allocate the
commands from process context so some of that crud will have to stay -
is that what you got from looking at the qlogic driver too? If you move
IET to the same model open-iscsi uses, where it operates from the
network's softirqs, then we will have to keep that delayed allocation
> don't need to know or access the inside of stgt_cmnd structure. Mike,
> What do you think?
For SCSI drivers if we can decipher the offset and len from the SCSI cdb
then I think I agree, if there are going to be weird commands that do
not fit into a transport or protocol or some generic place then I guess
target drivers may have to touch some things. Although I think I got
some things wrong. Today we do
target driver (queue cmnd/ alloc buffer) -> STGT (call protocol)
->protocol (SCSI stuff)
But I think we should go
target driver (queue cmnd alloc buffer) -> protocol (SCSI stuff) -> STGT
So then the target driver can pass some protocol specifc values like cdb
and lun (and lun decoder if necessary) without the stgt core having to
worry about that stuff. This will also allow you to make it so target
drivers do not have to touch things like the cdb field (I can move that
to a protocol specific cmnd data finally).
More information about the stgt