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

[FUJITA Tomonori]

From: Robert Jennings <rcj at linux.vnet.ibm.com>
Subject: Re: [Stgt-devel] [patch 1/2] passthrough target notification	function
Date: Thu, 31 May 2007 04:03:04 -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 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

Yes.

> and map more than one initiator to a target?

It doesn't matter.

> 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.

Because we need the scsi target state machine in kernel for that.


> 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?