[Stgt-devel] [patch 1/2] passthrough target notification function

[Robert Jennings]

* FUJITA Tomonori (fujita.tomonori at lab.ntt.co.jp) wrote:
> From: Robert Jennings <rcj at linux.vnet.ibm.com>
> Subject: Re: [Stgt-devel] [patch 1/2] passthrough target notification function
> Date: Wed, 30 May 2007 21:33:49 -0500
> 
> > * FUJITA Tomonori (fujita.tomonori at lab.ntt.co.jp) wrote:
> > > From: Robert Jennings <rcj at linux.vnet.ibm.com>
> > > Subject: Re: [Stgt-devel] [patch 1/2] passthrough target notification function
> > > Date: Wed, 30 May 2007 20:26:29 -0500
> > > 
> > > > * FUJITA Tomonori (fujita.tomonori at lab.ntt.co.jp) wrote:
> > > > > From: Robert Jennings <rcj at linux.vnet.ibm.com>
> > > > > Subject: [Stgt-devel] [patch 1/2] passthrough target notification function
> > > > > Date: Fri, 18 May 2007 13:17:45 -0500
> > > > > 
> > > > > > We spoke about this last week on the mailing list in relation to 
> > > > > > pass-through for kernel lld's.  This would notify scsi_tgt of any
> > > > > > target logical units that should be handled in the kernel.  Here is a
> > > > > > first pass, this is the user-space portion.
> > > > > > 
> > > > > > Send target state updates to the kernel (in-kernel pass-through enablement)
> > > > > 
> > > > > Thanks a lot.
> > > > > 
> > > > > From a quick look, you try to bind an lld to a scsi_host? If so, we
> > > > > can't (yeah, user-space code does something like that, but it's
> > > > > wrong. it needs be fixed). We need to bind a scsi_host to a tgt
> > > > > scsi_host (please read the previous pass-through discussion).
> > > > 
> > > > If I'm understanding you correctly, the target software assigns one
> > > > scsi_host to only one remote initiator.  This would mean that you want to
> > > > assign an entire physical adapter on the target side to a tgt scsi_host
> > > > that an initiator will see?  And then this would be a 1:1 relationship
> > > > of initiator to target.  Is this all correct?
> > > 
> > > Yeah, that's all correct though an entire physical adapter would be an
> > > entire virtual adapter with NPIV.
> > 
> > For ibmvstgt, NPIV wouldn't be involved so I would have to dedicate
> > an entire scsi adapter and all storage attached to it for each
> > initiator?
> 
> Yeah. Another option would be sending SCSI commands to user space
> once. But I don't know it's worth implementing such feature.

I want to pursue a more fine-grained approach.  With the hardware that
supports the ibmvstgt driver the end-user can already assign an I/O
slot to a paritition; providing functionality that maps tgt scsi_host
to scsi_host would be unproductive.  I would like to find a way to
map scsi_device to tgt scsi_lu in a 1:1 relationship for pass-through,
along with the other target types, I think this would provide the most
value to the end-user.

I'm trying to understand the decision because I've missed something.
Were you wanting to bind the scsi_host to a tgt scsi_host and map
more than one initiator to a target?  If not, if we maintained a 1:1
relationship, then I haven't followed why we can't bind a scsi_device
to a tgt scsi_lu.  Wouldn't scsi reservations and event notification
work with that binding, with the caveat that there be no local access
because that breaks the 1:1 relationship?