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