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

[FUJITA Tomonori]

From: Mike Christie <michaelc at cs.wisc.edu>
Subject: Re: [Stgt-devel] stgt & IBM virtual SCSI Target Driver
Date: Thu, 08 Sep 2005 15:44:10 -0500

> > 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?

Yep. The qlogic driver allocates commands in interrupt context. My
first intention was preallocate the specified number of commands using
mempool (as session_init does). It works with iSCSI however, though
I'm not sure about other protocols. However, preallocating some
commands is a bit difficult now (please see the comment in
stgt_cmnd_create). So perhaps, we needs delayed command allocation
later on.


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

Yes.


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

I agreed. Now we should remove all protocol specific stuff in stgt. I
tried to do this (though I'm not sure whether I've done in a right way
about some of the changes).