Re: Ang: Re: [Stgt-devel] Re: [Iscsitarget-devel] stgt a new version of iscsi target?

[Dave C Boutcher <sleddog@us.ibm.com>]

On Thu, Dec 08, 2005 at 02:09:32PM -0600, Mike Christie wrote:
> James Bottomley wrote:
> >On Thu, 2005-12-08 at 13:10 -0600, Mike Christie wrote:
> >
> >>cleanup. In the end some of the scsi people liked the idea of throwing 
> >>the non-read/write command to userspace and to do this we just decided 
> >>to start over but I have been cutting and pasting your code and cleaning 
> >>it up as I add more stuff.
> >
> >
> >To be honest, I'd like to see all command processing at user level
> >(including read/write ... for block devices, it shouldn't be that
> >inefficient, since you're merely going to say remap an area from one
> >device to another; as long as no data transformation ever occurs, the
> >user never touches the data and it all remains in the kernel page
> >cache).
> 
> Ok, Tomo and I briefly talked about this when we saw Jeff's post about 
> doing block layer drivers in userspace on lkml. I think we were somewhat 
> prepared for this given some of your other replies.
> 
> So Vlad and other target guys what do you think? Vlad are you going to 
> continue to maintain scst as kernel only, or is there some place we can 
> work together on this on - if your feelings are not hurt too much that 
> is :) ?

Oofff....Architecturally I agree with James...do all command processing
in one place.  On the other hand, the processing involved with a read or
write in the normal case (no aborts/resets/ordering/timeouts/etc) is
almost zero.  Figure out the LBA and length and pass on the I/O.  The
overhead of passing it up and down across the kernel boundary is likely
to be orders of magnitude larger than the actual processing.  I would
personally rather not fix this decision in concrete until we could do
some actual measurements of a SCSI target under heavy load.

-- 
Dave Boutcher