[Stgt-devel] stgt & IBM virtual SCSI Target Driver

[Mike Christie]

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 
code too.

> 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).