FCP target reset

FCP target reset

[Christof Schmitt]

While trying to replace the Fibre Channel protocol definitions in
zfcp with the definitions in include/scsi/fc i came across the FCP
target reset flag.

>From what i understand, older versions of the FCP standard defined the
target reset flag, but newer versions do not. Adhering to the newer
standard, the file include/scsi/fc/fc_fcp.h does not define the target
reset.

Does this mean that FC device drivers should not issue target resets
any more?

Some FC device drivers in Linux define the flag:

grep -r FCP_TARGET_RESET *
drivers/s390/scsi/zfcp_dbf.h:	zfcp_scsi_dbf_event(flag == FCP_TARGET_RESET ? "trst" : "lrst", tag, 1,
drivers/s390/scsi/zfcp_def.h:#define FCP_TARGET_RESET	0x20
drivers/s390/scsi/zfcp_scsi.c:	return zfcp_task_mgmt_function(scpnt, FCP_TARGET_RESET);
drivers/scsi/lpfc/lpfc_scsi.c: FCP_TARGET_RESET);
drivers/scsi/lpfc/lpfc_scsi.c: FCP_TARGET_RESET);
drivers/scsi/lpfc/lpfc_scsi.h:#define  FCP_TARGET_RESET    0x20	/* bit 5 */

If the target reset is not required, i would remove it from zfcp. If
it is still required, would adding it to include/scsi/fc/fc_fcp.h make
sense, probably flagged as "obsolete"?

--
Christof Schmitt

Re: FCP target reset

[James Smart]

Just because a newer rev of the spec doesn't do something does not mean that 
all the targets/environments stopped using it...  Target Reset was a mandatory 
item for FCP-2 compliance, which is what most of the stuff in the field is at. 
   So, I recommend that the header be updated with the older definition - It 
can be flagged any way you desire (/* Deprecated as of FCP-3 */).

As for use in LLD's - there's nothing else (TMF-wise) that works at the I_T 
nexus level to map to the shost eh_target_reset_handler.  Thus, I'd continue 
to use it for the entrypoint. You can always choose to not implement the entry 
point, but my recommendation is to support it if possible. It's much better 
than having to resort to a "bus" or "adapter" reset after a lun reset fails.

-- james s

Christof Schmitt wrote:
> While trying to replace the Fibre Channel protocol definitions in
> zfcp with the definitions in include/scsi/fc i came across the FCP
> target reset flag.
> 
>>From what i understand, older versions of the FCP standard defined the
> target reset flag, but newer versions do not. Adhering to the newer
> standard, the file include/scsi/fc/fc_fcp.h does not define the target
> reset.
> 
> Does this mean that FC device drivers should not issue target resets
> any more?
> 
> Some FC device drivers in Linux define the flag:
> 
> grep -r FCP_TARGET_RESET *
> drivers/s390/scsi/zfcp_dbf.h:	zfcp_scsi_dbf_event(flag == FCP_TARGET_RESET ? "trst" : "lrst", tag, 1,
> drivers/s390/scsi/zfcp_def.h:#define FCP_TARGET_RESET	0x20
> drivers/s390/scsi/zfcp_scsi.c:	return zfcp_task_mgmt_function(scpnt, FCP_TARGET_RESET);
> drivers/scsi/lpfc/lpfc_scsi.c: FCP_TARGET_RESET);
> drivers/scsi/lpfc/lpfc_scsi.c: FCP_TARGET_RESET);
> drivers/scsi/lpfc/lpfc_scsi.h:#define  FCP_TARGET_RESET    0x20	/* bit 5 */
> 
> If the target reset is not required, i would remove it from zfcp. If
> it is still required, would adding it to include/scsi/fc/fc_fcp.h make
> sense, probably flagged as "obsolete"?
> 
> --
> Christof Schmitt
> --
> 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: FCP target reset

[Christof Schmitt]

On Mon, Aug 03, 2009 at 04:38:32PM -0400, James Smart wrote:
> Just because a newer rev of the spec doesn't do something does not mean 
> that all the targets/environments stopped using it...  Target Reset was a 
> mandatory item for FCP-2 compliance, which is what most of the stuff in 
> the field is at.   So, I recommend that the header be updated with the 
> older definition - It can be flagged any way you desire (/* Deprecated as 
> of FCP-3 */).
>
> As for use in LLD's - there's nothing else (TMF-wise) that works at the 
> I_T nexus level to map to the shost eh_target_reset_handler.  Thus, I'd 
> continue to use it for the entrypoint. You can always choose to not 
> implement the entry point, but my recommendation is to support it if 
> possible. It's much better than having to resort to a "bus" or "adapter" 
> reset after a lun reset fails.

I agree that it makes sense to keep this. My question resulted partly
from the confusion about the removal of this function in recent specs.
Here is a patch to add the target reset flag to the FCP header file to
use it in zfcp (and other SCSI FC drivers).

Christof
---
SCSI: Add target reset flag to FCP header file

From: Christof Schmitt <christof.schmitt@de.ibm.com>

While the target reset task management function has been deprecated in
newer specs, it is still in use by SCSI FC drivers and there is no real
replacement. Add the target reset flag to the FCP header file to allow
use of this definition in SCSI FC drivers.

Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com>
---
 include/scsi/fc/fc_fcp.h |    2 ++
 1 file changed, 2 insertions(+)

--- a/include/scsi/fc/fc_fcp.h	2009-03-24 13:50:59.000000000 +0100
+++ b/include/scsi/fc/fc_fcp.h	2009-08-04 10:28:50.000000000 +0200
@@ -84,6 +84,8 @@ struct fcp_cmnd32 {
  */
 #define	FCP_TMF_CLR_ACA		0x40	/* clear ACA condition */
 #define	FCP_TMF_LUN_RESET	0x10	/* logical unit reset task management */
+#define	FCP_TMF_TGT_RESET	0x20	/* target reset task management,
+					   deprecated as of FCP-3 */
 #define	FCP_TMF_CLR_TASK_SET	0x04	/* clear task set */
 #define	FCP_TMF_ABT_TASK_SET	0x02	/* abort task set */
 

Re: FCP target reset

[Douglas Gilbert]

It looks like "target reset" is being phased out of SCSI
terminology and being partially replaced by "hard reset".

The third paragraph in the introduction of draft SAM-5
(sam5r02.pdf section 1.1) states:

"The following concepts from previous versions of this
  standard are made obsolete by this standard:
    a)    support for the SPI-5 SCSI transport protocol;
    b)    Contingent Allegiance;
    c)    the TARGET RESET task management function;
    d)    basic task management model;
    e)    untagged tasks; and
    f)    linked command function."

The TARGET RESET task management function last appeared
in SAM-2 (ANSI INCITS 366-2003).

A "hard reset" is associated with a power cycle at an
initiator, target or somewhere in between. There is no
SCSI task management function to generate a hard reset.

Some transports have the ability to generate hard resets
via non-SCSI protocols. For example in SAS a target can
be reset with a SMP PHY CONTROL request to an expander
phy attached to a phy on that target. SAS also has a lower
order "link reset" which is invisible at the SCSI protocol
level.

So is there a "hard reset" hook somewhere in FCP-3 ?

Doug Gilbert


James Smart wrote:
> Just because a newer rev of the spec doesn't do something does not mean 
> that all the targets/environments stopped using it...  Target Reset was 
> a mandatory item for FCP-2 compliance, which is what most of the stuff 
> in the field is at.   So, I recommend that the header be updated with 
> the older definition - It can be flagged any way you desire (/* 
> Deprecated as of FCP-3 */).
> 
> As for use in LLD's - there's nothing else (TMF-wise) that works at the 
> I_T nexus level to map to the shost eh_target_reset_handler.  Thus, I'd 
> continue to use it for the entrypoint. You can always choose to not 
> implement the entry point, but my recommendation is to support it if 
> possible. It's much better than having to resort to a "bus" or "adapter" 
> reset after a lun reset fails.
> 
> -- james s
> 
> Christof Schmitt wrote:
>> While trying to replace the Fibre Channel protocol definitions in
>> zfcp with the definitions in include/scsi/fc i came across the FCP
>> target reset flag.
>>
>>> From what i understand, older versions of the FCP standard defined the
>> target reset flag, but newer versions do not. Adhering to the newer
>> standard, the file include/scsi/fc/fc_fcp.h does not define the target
>> reset.
>>
>> Does this mean that FC device drivers should not issue target resets
>> any more?
>>
>> Some FC device drivers in Linux define the flag:
>>
>> grep -r FCP_TARGET_RESET *
>> drivers/s390/scsi/zfcp_dbf.h:    zfcp_scsi_dbf_event(flag == 
>> FCP_TARGET_RESET ? "trst" : "lrst", tag, 1,
>> drivers/s390/scsi/zfcp_def.h:#define FCP_TARGET_RESET    0x20
>> drivers/s390/scsi/zfcp_scsi.c:    return 
>> zfcp_task_mgmt_function(scpnt, FCP_TARGET_RESET);
>> drivers/scsi/lpfc/lpfc_scsi.c: FCP_TARGET_RESET);
>> drivers/scsi/lpfc/lpfc_scsi.c: FCP_TARGET_RESET);
>> drivers/scsi/lpfc/lpfc_scsi.h:#define  FCP_TARGET_RESET    0x20    /* 
>> bit 5 */
>>
>> If the target reset is not required, i would remove it from zfcp. If
>> it is still required, would adding it to include/scsi/fc/fc_fcp.h make
>> sense, probably flagged as "obsolete"?
>>
>> -- 
>> Christof Schmitt
>> -- 
>> 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
>>
> -- 
> 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: FCP target reset

[James Smart]

Douglas Gilbert wrote:
> It looks like "target reset" is being phased out of SCSI
> terminology and being partially replaced by "hard reset".

Well, there's still an "I_T Nexus Reset" within the TMF area, which FCP-4 
provides no mapping for, but does define how to create a I_T Nexus loss event.

Headache is there's history... SPI BDRs did full target resets and killed i/o 
for all initiators. Target Reset and FCP-2 gave same kind of semantic. FCP-3 
and later tried to make initiators better citizens and isolate reset semantics 
if possible. Unfortunately, there's lots of users that equate FC to SCSI, SCSI 
to SPI, and assume SPI-like semantics. So changing things just to be 
standard-compliant always seems to upset someone (and it's usually the most 
critical someone).

> The third paragraph in the introduction of draft SAM-5
> (sam5r02.pdf section 1.1) states:
> 
> "The following concepts from previous versions of this
>   standard are made obsolete by this standard:
>     a)    support for the SPI-5 SCSI transport protocol;
>     b)    Contingent Allegiance;
>     c)    the TARGET RESET task management function;
>     d)    basic task management model;
>     e)    untagged tasks; and
>     f)    linked command function."
> 
> The TARGET RESET task management function last appeared
> in SAM-2 (ANSI INCITS 366-2003).
> 
> A "hard reset" is associated with a power cycle at an
> initiator, target or somewhere in between. There is no
> SCSI task management function to generate a hard reset.
> 
> Some transports have the ability to generate hard resets
> via non-SCSI protocols. For example in SAS a target can
> be reset with a SMP PHY CONTROL request to an expander
> phy attached to a phy on that target. SAS also has a lower
> order "link reset" which is invisible at the SCSI protocol
> level.
> 
> So is there a "hard reset" hook somewhere in FCP-3 ?

Only mapping in FCP-4 is Loop-based. Nothing for non-Loop.

All other events correspond to I_T Nexus Loss and center around login/logout.

For the target_reset entry point, I assume generating something for an I_T 
Nexus Loss should be fine. However, it goes against those SPI-isms mentioned 
above and can also be a real pain for the driver (discovery sucks). Given all 
the history, the OEM test scripts, and bars we've passed to date, I'm very 
hesitant to move away from Target Reset.

If we're really going to solve it, it probably requires more than the simple 
heirarchial device/tgt/bus/adapter reset escalation entry points (ex: does bus 
reset hard-reset all targets, or just terminate local I_T nexus related ios ?) 
- and another can of worms.


-- james s

Re: FCP target reset

[James Bottomley]

On Tue, 2009-08-04 at 12:03 -0400, James Smart wrote:
> 
> Douglas Gilbert wrote:
> > It looks like "target reset" is being phased out of SCSI
> > terminology and being partially replaced by "hard reset".
> 
> Well, there's still an "I_T Nexus Reset" within the TMF area, which FCP-4 
> provides no mapping for, but does define how to create a I_T Nexus loss event.
> 
> Headache is there's history... SPI BDRs did full target resets and killed i/o 
> for all initiators. Target Reset and FCP-2 gave same kind of semantic. FCP-3 
> and later tried to make initiators better citizens and isolate reset semantics 
> if possible. Unfortunately, there's lots of users that equate FC to SCSI, SCSI 
> to SPI, and assume SPI-like semantics. So changing things just to be 
> standard-compliant always seems to upset someone (and it's usually the most 
> critical someone).

The headache with dropping TDR is going to be SCSI-2 reservations.  They
need some type of reset to trigger release.  LUN reset will do it, but
it's a new addition and we don't currently have a SG_SCSI_RESET_XXX
allocated to it so there's no way userland can request it at the moment.

James