Re: stgt a new version of iscsi target?

[Mike Christie <michaelc@cs.wisc.edu>]

Vladislav Bolkhovitin wrote:
> James Bottomley wrote:
> 
>> On Fri, 2005-12-09 at 18:29 +0300, Vladislav Bolkhovitin wrote:
>>
>>>> Additionally, it's perfectly possible for all of this to be done zero
>>>> copy on the data.  A user space target mmaps the data on its storage
>>>> device and then does a SG_IO type scatter gather user virtual region
>>>> pass to the underlying target infrastructure.  We already have this
>>>> demonstrated in the SG_IO path, someone just needs to come up with the
>>>> correct implementation for a target path.
>>>
>>>
>>> I'm not completely understand how it will work. Consider, there are 
>>> READ/WRITE commands with random data sizes arrive from an initiator. 
>>> Are you going to do map/unmap for each command individually or alloc 
>>> data buffers for commands from a premapped area and live with 
>>> possible its fragmentation? If map/unmap individually, then I should 
>>> say that those are very expensive operations.
>>
>>
>> You do it the same way an array does:  the model for SPI is read command
>> phase, disconnect, process command (i.e. set up areas) reconnect for
>> data transfer.
>>
>> map/unmap are really only necessary if you're emulating the data store,
>> but it's a fairly cheap operation on linux: it just causes the creation
>> of a vm_area.  If it's a pass through, you can use SG_IO to pull it in
>> and the SG_IO like output to shoot it out again, effectively using a
>> piece of user memory as a zero copy buffer.
>>
>> Fragmentation isn't an issue because the I/O goes via sg lists , all
>> that's needed is a bunch of pages.
> 
> 
> OK, I see what you meant, thanks.
> 
>> I do have to say that I consider operation in interrupt context (or even
>> kernel context) to be a disadvantage.  Compared with the response times
>> that most arrays have to SCSI commands, the kernel context switch time
>> isn't that significant.
> 
> 
> Are you sure that there are no now or will be available in the nearest 
> feature such (eg iSCSI) SCSI arrays with response time/latency so small 
> that having 5 (five) context switches or more per command, some of which 
> include map/unmap operations, will not increase the latency too much? I 
> mean, eg NFS server, which originally was user space daemon and many 
> people didn't want it in the kernel. Eventually, it's in. I don't see 
> any fundamental difference between NFS server and SCSI target server, 

Isn't the reason a NFS server is still in the kernel is becuase some of 
the locking difficulties?