FCP target reset

DISCUSSION Christof Schmitt 4 participants 6 messages Aug 3, 2009 – Aug 4, 2009

Subsystems (2)

SCSI FCoE subsystem (libfc, libfcoe, fcoe)

lore

Share & tools

lore

Christof Schmitt

author

2009-08-03 16:23 UTC #0 lore raw

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.

Quoted 1 line

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

James Smart

2009-08-03 20:38 UTC #1 lore raw

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

Quoted 33 lines · 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.
Quoted 1 line
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Christof Schmitt

author

2009-08-04 08:46 UTC #2 lore raw

Quoted 7 lines · 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 */).

Quoted 6 lines

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 <[email protected]>

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 <[email protected]>

---
 include/scsi/fc/fc_fcp.h |    2 ++
 1 file changed, 2 insertions(+)

include/scsi/fc/fc_fcp.h +2 -0

@@ -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 */

Douglas Gilbert

2009-08-04 14:38 UTC #3 lore raw

In reply to James Smart

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

Quoted 45 lines · 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
Quoted 33 lines · 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.
Quoted 1 line
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"?
Signature · 5 lines
Christof Schmitt
-- 
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Signature · 3 lines
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

James Smart

2009-08-04 16:04 UTC #4 lore raw

Quoted 2 lines · Douglas Gilbert

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

Quoted 19 lines

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.

Quoted 8 lines

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

James Bottomley

maintainer

2009-08-04 16:20 UTC #5 lore raw

Quoted 8 lines · James Smart

Quoted 2 lines · Douglas Gilbert
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.

Quoted 7 lines

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