FCP Recovery Abort

Kurt Chan kc at core.rose.hp.com
Mon Aug 1 12:26:52 PDT 1994

| Since an initiator may have a very large number of open exchanges with
| a target during any of the above operations, a very large number of
| recovery abort operations may occur whenever one of the above
| functions is performed. On the other hand, if targets performed
| recovery aborts on ambiguous exchanges as now required, only a very
| few recovery abort operations would occur. Instead of assuming that
| all open exchanges are ambiguous, the initiator can depend on the
| target to abort the exchanges which it knows are ambiguous (i.e. with
| unacknowledged frames), and the other exchanges can simply be erased
| from memory.
| For this reason, I favor leaving FCP exactly as it is in rev 8b.
|                                 Giles Frazier
|                                 IBM Austin
|                                 gfrazier at ausvm6.vnet.ibm.com

OK - let me see if I understand this position.  Assume there are 3
Initiators sharing 10 Targets, and each Initiator has 20 Commands
pending to each Target for a total of 3x10x20 = 600 commands pending
in the SCSI Domain.  Now let's say each Target receives a Target
Reset from one of it's 3 Initiators.

The extreme example is that the 10 Targets must each perform 3*20 = 60
Recovery Abort procedures apiece.  The other extreme is that the 3
Initiators must each perform 10*20 = 200 Recovery Abort Procedures
apiece.  Either way, the domain experiences the same number of
Recovery Abort procedures if all the Exchanges are "ambiguous"
|from one perspective or the other.

Now consider the 7 places where a Task Management function can arrive
at a Target during a class 3 FCP Exchange.  Assume the Target receives
a TARGET RESET in each of these places, creates a Unit Attention
condition for the Initiator, and instantaneously halts further
processing of the Exchange:

  Write Cmd --------->                Read Cmd  --------->
               (1)                                  (1)        
            <--------  XFR_RDY                  <-------- Data
               (2)                                  (2)                 
      Data  --------->                          <-------- Data
               (3)                                  (3)
      Data  --------->                          <-------- FCP_RSP
            <--------  FCP_RSP

At (2) on Writes the Initiator is fully interlocked and the Exchange
is "quiesced" pending further Initiator action.  Likewise, at (1) on
Reads, and (4) on Writes, the *Target* is fully interlocked (assuming
all data has been accounted for in the Write case).

Are we saying that ABTS-LS does not need to be performed AT ALL if
Task Management takes place at these interlock points?  I would guess
that distinguishing between Write (2) versus the other 6 protocol
states at the Initiator may be more "work" for the Initiator than
simply explicitly aborting all tasks that it has not recevied FCP_RSP

Similarly, will Targets be required to differentiate between Read
(1)/Write(4) states and the other 5 states before deciding whether
to initiate ABTS?

If not, I fail to see the impact on simplicity or performance if ABTS
initiation is required to be shared between Initiator and Target
versus owned by the Initiator.  The measurable difference is not
architectural, but pragmatic:  The Initiator will ALWAYS have FW/SW to
initiate Recovery Abort, but as I demonstrated in my analysis, it is
possible to design a class 3 Target that DOESN'T require this function
and still have a reliable, efficient recovery protocol.

Since I don't believe there are cost/complexity/performance benefits
to be gained by requiring Targets to do ABTS, but I do believe there
are cost/complexity benefits to the Target in allowing them NOT to, I
continue to recommend FCP Rev 8b be changed to allow Targets NOT to
initiate ABTS.

This is not to say I cannot be persuaded otherwise - if a cry arises
|from real Target implementors that they cannot live without initiating
ABTS, then I'll gladly concede my position and move on to more
interesting subjects.

Kurt Chan        
kc at core.rose.HP.com

More information about the T10 mailing list