Proposed Responses to additional Fibre Channel Protocol questions
Kurt Chan
kc at core.rose.hp.com
Wed Jun 15 13:52:10 PDT 1994
| A) Use of Error Abort (Jim Coomes, Seagate)
|
| Comment:
|
| We would like to eliminate requirements for target to send
| ABTS to host after:
|
| FCP Logout
| Target reset
| Clear Task Set
| Abort Task Set
The wording that I believe Jim is having problems with is:
"Any open Exchanges that are in an ambiguous state shall be
terminated by whicever port detects the ambiguous state
using a Recovery Abort."
This does not necessarily require that Targets initiate ABTS. I define
an "ambiguous" condition as one where an I/O may have different states
depending upon which end of the cable you're on.
>From the INITIATOR's perspective, an I/O is in an ambiguous state if:
- In class 2, no acknowledgement is received for a CMD, or
- In class 3, no XFR_RDY or Read Data is received for a CMD.
- In any class, if all data has been transferred successfully and
it is waiting for RSP from the Target.
>From the TARGET's perspective, if
- In class 2, if no acknowledgment is received for a RSP,
- In class 3, from the time until RSP is sent until a duplicate OX_ID
is received from the same Initiator
For Targets, it is irrelevant whether or not the host has received the
RSP. If it did not, it will retry the command with a new OX_ID. The
Target need not attempt to determine whether or not the command is in
an ambiguous state, and therefore it need not take any explicit
action. Instead, I believe Targets should rely on the implicit Host
knowledge of whether or not commands are outstanding, and require that
Hosts be responsible for error recovery actions when FCP Logout,
Target Reset, Clear Task Set, or Abort Task Set have been invoked
while commands are in indeterminate states.
I don't believe any changes to FCP are needed.
| D) TTD/CIOP (Brian Doore, Seagate, Brian_Doore at notes.seagate.com)
|
| Comment:
|
| For implementation of our new Raid-assist functions, we have a
| need to prevent a target from sending Read data until the host
| grants permission, similar to what is currently done in
| regular SCSI with TTD/CIOP messages. The Read XFER_RDY
| defined in FCP could be used for this but does not currently
| work because there is no interlocking acknowledgement from the
| host (class 3).
I know there is a temptation to solve this problem within smaller
groups, but I agree that this functionality (defining how a host can
dispatch multiple READ commands and then flow control the subsequent
incoming READ data) should be defined within SAM, rather than create
multiple link-specific solutions.
We can then figure out how to map this functionality into FCP.
Regards,
Kurt Chan Hewlett-Packard System Interconnect Lab
kc at core.rose.hp.com Voice: 916-785-5621 Fax: 916-785-2875
8000 Foothills Blvd MS R5NF Roseville, CA 95747
More information about the T10
mailing list