[Stgt-devel] Question for pass-through target design

[Vladislav Bolkhovitin]

Vladislav Bolkhovitin wrote:
> FUJITA Tomonori wrote:
> 
>> From: Vladislav Bolkhovitin <vst at vlnb.net>
>> Subject: Re: [Stgt-devel] Question for pass-through target design
>> Date: Mon, 07 May 2007 19:27:23 +0400
>>
>>
>>> FUJITA Tomonori wrote:
>>>
>>>> From: Vladislav Bolkhovitin <vst at vlnb.net>
>>>> Subject: Re: [Stgt-devel] Question for pass-through target design
>>>> Date: Mon, 07 May 2007 18:24:44 +0400
>>>>
>>>>
>>>>
>>>>> FUJITA Tomonori wrote:
>>>>>
>>>>>
>>>>>>>>> It looks like the pass-through target support is currently 
>>>>>>>>> broken, at
>>>>>>>>> least as I've checked for ibmvstgt, but I think it's a general 
>>>>>>>>> problem.
>>>>>>>>> I wanted to check my assumptions and get ideas.
>>>>>>>>
>>>>>>>>
>>>>>>>> Yeah, unfortunately, it works only with the iSCSI target driver 
>>>>>>>> (which
>>>>>>>> runs in user space).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> The code isn't allocating any memory to pass along to the sg 
>>>>>>>>> code to store
>>>>>>>>> the result of a read or data for a write.  Currently, dxferp 
>>>>>>>>> for sg_io_hdr
>>>>>>>>> or dout_xferp/din_xferp for sg_io_v4 are assigned to the value 
>>>>>>>>> of uaddr,
>>>>>>>>> which is set to 0 in kern_queue_cmd.  With the pointer set to 
>>>>>>>>> NULL,
>>>>>>>>> the pass-through target isn't going to function.  Even if we 
>>>>>>>>> had memory
>>>>>>>>> allocated, there isn't a means of getting data to be written 
>>>>>>>>> via sg down
>>>>>>>>> this code path.
>>>>>>>>>
>>>>>>>>> What ideas are there as to how the data will get to user-space 
>>>>>>>>> so that
>>>>>>>>> we can use sg?
>>>>>>>>
>>>>>>>>
>>>>>>>> For kernel-space drivers, we don't need to go to user-space. We 
>>>>>>>> can do
>>>>>>>> the pass-through in kernel space. I talked with James about this 
>>>>>>>> last
>>>>>>>> year and he said that if the code is implemented cleanly, he would
>>>>>>>> merges it into mainline.
>>>>>>>
>>>>>>>
>>>>>>> We already have a pass-through in the kernel space for
>>>>>>> kernel space drivers. It is the scsi_tgt* code.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Could you elaborate more?
>>>>>>
>>>>>> What I meant that is that the kernel tgt code (scsi_tgt*) receives
>>>>>> SCSI commands from one lld and send them to another lld instead of
>>>>>> sending them to user space.
>>>>>
>>>>>
>>>>> Although the approach of passing SCSI commands from a target LLD to an
>>>>> initiator one without any significant interventions from the target
>>>>> software looks to be nice and simple, you should realize how limited,
>>>>> unsafe and illegal it is, since it badly violates SCSI specs.
>>>>
>>>>
>>>>
>>>> I think that 'implemented cleanly' means that one scsi_host is assigned
>>>> to only one initiator.
>>>
>>>
>>> Sorry, I don't fully understand you. If you mean you are going to 
>>> limit only one remote initiator per-target device, then, well, is it 
>>> even more limited (and limiting) or not?
>>
>>
>>
>> The target software assigns one scsi_host to only one remote
>> initiator. For FC, NPIV works nicely.
> 
> 
> OK, if such limitation is OK for your users, then I'm happy for you.

And don't forget to tell them that they must not touch the exported 
devices locally ;)

>> _______________________________________________
>> Stgt-devel mailing list
>> Stgt-devel at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/stgt-devel
>>
> 
>