[PATCH 0/8] target mode support

[PATCH 0/8] target mode support

[FUJITA Tomonori]

The following patchset adds the target mode support in
user-space. This has been living in the -mm tree for a while. Mike and
I think it's ready for mainline inclusion.

The user-space tools and documents are available at:

http://stgt.berlios.de/

This patchset can be applied to both scsi-misc-2.6 and linux-2.6
trees.


The first two patches are for the block layer. The second patch is the
following 'support larger block pc requests' patch in the bsg tree:

http://kernel.org/git/?p=linux/kernel/git/axboe/linux-2.6-block.git;a=commitdiff;h=d872a1b22a09dffd7b48609f80f80dfa6e78227e

It's a slightly modified version since scsi_ioctl.c in the bsg tree
was cleaned up.

Re: [PATCH 0/8] target mode support

[James Smart]

One question....

Does this assume that an hba is both initiator and target ?  target only ?
Do we have any issues if a scsi_host is a target only ?

-- james s

FUJITA Tomonori wrote:
> The following patchset adds the target mode support in
> user-space. This has been living in the -mm tree for a while. Mike and
> I think it's ready for mainline inclusion.
> 
> The user-space tools and documents are available at:
> 
> http://stgt.berlios.de/
> 
> This patchset can be applied to both scsi-misc-2.6 and linux-2.6
> trees.
> 
> 
> The first two patches are for the block layer. The second patch is the
> following 'support larger block pc requests' patch in the bsg tree:
> 
> http://kernel.org/git/?p=linux/kernel/git/axboe/linux-2.6-block.git;a=commitdiff;h=d872a1b22a09dffd7b48609f80f80dfa6e78227e
> 
> It's a slightly modified version since scsi_ioctl.c in the bsg tree
> was cleaned up.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH 0/8] target mode support

[Mike Christie]

James Smart wrote:
> One question....
> 
> Does this assume that an hba is both initiator and target ?  target only ?
> Do we have any issues if a scsi_host is a target only ?
> 

I do not think that is fully worked out yet. The only target that is
done is the vscsi one which is a little different from something like
lpfc or qla*. I think some developers like Qlogic would prefer the
driver and card is only in one mode or the other to simplify things.
However, I think Tomo and users would like to be able to use a
card/driver in both modes at the same time.

Re: [PATCH 0/8] target mode support

[James Smart]

Ok.  My assumption is that it is preferred to be a single mode, but that
dual mode should be supported.  Please note that dual mode may impact some
of the feature set in the emulated target - and it'll be a trick to identify
that.

Hmm... what this leads me to is - there is a difference between the
pure SCSI behavior (performing a SCSI Read command), and the transport-level
SCSI behavior (Mode Pages; FCP: Conf, Recovery; iSCSI CmdSN/StatSN progression,
SNACK, RSP retransmission, etc). Although, these will be very tightly
integrated.  How does this code account for this ?  Are there transport-level
libraries in-between the LLDD and the SCSI Target ? Is it reflected in the
LLDD to SCSI Target messaging ?

-- james


Mike Christie wrote:
> James Smart wrote:
>> One question....
>>
>> Does this assume that an hba is both initiator and target ?  target only ?
>> Do we have any issues if a scsi_host is a target only ?
>>
> 
> I do not think that is fully worked out yet. The only target that is
> done is the vscsi one which is a little different from something like
> lpfc or qla*. I think some developers like Qlogic would prefer the
> driver and card is only in one mode or the other to simplify things.
> However, I think Tomo and users would like to be able to use a
> card/driver in both modes at the same time.
> 

Re: [PATCH 0/8] target mode support

[Mike Christie]

James Smart wrote:
> Ok.  My assumption is that it is preferred to be a single mode, but that
> dual mode should be supported.  Please note that dual mode may impact some
> of the feature set in the emulated target - and it'll be a trick to
> identify
> that.
> 
> Hmm... what this leads me to is - there is a difference between the
> pure SCSI behavior (performing a SCSI Read command), and the
> transport-level
> SCSI behavior (Mode Pages; FCP: Conf, Recovery; iSCSI CmdSN/StatSN
> progression,
> SNACK, RSP retransmission, etc). Although, these will be very tightly
> integrated.  How does this code account for this ?  Are there
> transport-level
> libraries in-between the LLDD and the SCSI Target ? Is it reflected in the

I do not think it is a layer like how you might think or want. It is
more of a library like how scsi-ml, the current transport classes or
libata is. I do not think we are submitting anything that works both in
initiator and target mode today, but the SCSI RDMA Protocol library is
an example of just a target library.

For a lib/class that works in both modes I will use iscsi as an example
even though we just threw that target to userspace. In the iscsi_tcp_tgt
patches where it was in the kernel that I sent a couple months ago

http://marc.theaimsgroup.com/?l=linux-scsi&m=115639258024577&w=2

Tomo modified the current iscsi transport class (iscsi class in upstream
kernel is a common code for all iscsi drivers) and libiscsi (libiscsi is
common code for just software iscsi and iser and partial iscsi offload
drivers) so that it could be used by a target mode driver. Common
components like the recv path which would take a network packet and
assemble it into a iscsi command were modified so they could be used by
a initiator or target and put in libiscsi. Same goes for the send path
as far as taking a iscsi packet and putting it on the network.

Then where an initiator and target would differ went into seperate
modules. For iscsi_tcp_tgt, the target code would maintain things needed
for its specific transport state model. To perform the common scsi
operations, the LLD would either call the scsi_tgt_lib function directly
and have its transfer_data or transfer_response callouts directly (this
would be the case like with qla4xxx where the card hides pretty much all
the iscsi details from the driver when in session mode), or the LLD
would call some transport specific lib function which would be a wrapper
around the scsi_tgt_lib function like is done with the transport classes
and libata today. The transport specific lib function would also call
into the LLD through some transport callout like with the initiators.

So for lpfc, I asked about your thoughts on how this would work for
scsi_transport_fc and if we should just make a completely seperate
module for the target, but I am not sure what we agreed on. For iscsi it
was possible to integrate initiator and target support in a lot of
places because a most of the code is in userspace and we have userspace
libraries as well as kernel ones so that is where most of those detailes
live :) And I have not got a chance to work on Fibre Channel for a long
time. Lots of iscsi initiator bugs :)

What are your thoughts? For a LLDs like lpfc or qla2xxx, I do not think
it is going to be best to seperate out things like the ineterrupt
processing into seperate modules like was done with software iscsi and I
am not sure FC drivers will be able to reuse structs like the rport for
both modes (we did this for iscsi with the iscsi_connecion/iscsi_session).

I have not done much work on lpfc for a long long time. For qla2xxx, we
just merged the target specifc interrupt handling and setup code into
the one driver. This was over a year ago so qla2xxx was not integrated
into the FC class and using rports like today so we did not have to
worry about that too. Should a single rport struct support both modes or
just one



> LLDD to SCSI Target messaging ?
> 
> -- james
> 
> 
> Mike Christie wrote:
>> James Smart wrote:
>>> One question....
>>>
>>> Does this assume that an hba is both initiator and target ?  target
>>> only ?
>>> Do we have any issues if a scsi_host is a target only ?
>>>
>>
>> I do not think that is fully worked out yet. The only target that is
>> done is the vscsi one which is a little different from something like
>> lpfc or qla*. I think some developers like Qlogic would prefer the
>> driver and card is only in one mode or the other to simplify things.
>> However, I think Tomo and users would like to be able to use a
>> card/driver in both modes at the same time.
>>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/8] target mode support

[FUJITA Tomonori]

From: James Smart <James.Smart@Emulex.Com>
Subject: Re: [PATCH 0/8] target mode support
Date: Thu, 16 Nov 2006 09:33:53 -0500

> One question....
> 
> Does this assume that an hba is both initiator and target ?  target only ?
> Do we have any issues if a scsi_host is a target only ?

As Mike said, now a scsi_host can be used as a target only. We need
some more work to make one scsi_host support both initiator and target
mode. Can a LLD use two scsi_hosts (for initiator and target mode
respectively)?

Re: [PATCH 0/8] target mode support

[James Smart]

FUJITA Tomonori wrote:
> As Mike said, now a scsi_host can be used as a target only. We need
> some more work to make one scsi_host support both initiator and target
> mode. Can a LLD use two scsi_hosts (for initiator and target mode
> respectively)?

Sure.. a small amount of programming :)

It does help some of the presentation, but may do so at the cost of a
little code bloat.   Unfortunately, the technical issues of sharing the
transport port still exist, but that's true whether 1 or multiple
scsi_hosts are being used.

-- james s