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

Vladislav Bolkhovitin vst
Mon May 7 18:52:34 CEST 2007


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.

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




More information about the stgt mailing list