MORE ON FCP ABORT

GFRAZIER at ausvm6.vnet.ibm.com GFRAZIER at ausvm6.vnet.ibm.com
Mon Aug 1 12:54:22 PDT 1994


This is yet another note about FCP ABTS/LS sequence operations.

The way I look at it is as follows: In class 1 and 2,
potentially hundreds of ABTS/LS operations do not need to be done if
FCP remains unchaged. This is because a very large number of exchanges
may exist but a very small number of sequences may be ambiguous at the
target. (Please refer to FCP 8b for definition of ambiguous.)
This situation occurs when the initiator has a very
large number of commands (open exchanges) at the target but the target
only has a single ambiguous exchange. (e.g. one of the exchanges has
an unacknowledged frame but all the rest of the exchanges are
quiescient--the target has acknowledged the command but is accessing
the data.)

When the initiator can depend on the target to abort this small number
of ambiguous exchanges, a small number of ABTS/LS operations are
required; when the initiator can't depend on the target for this, it
must assume they are all ambiguous and abort them all.

There is another solution which may pertain more to class 3 but could
also be used: The initiator may wait RA_TOV before reusing any of the
XID's.
This may be the only reliable method for class 3 anyway.
                               Giles Frazier
                               IBM Austin
                               gfrazier at austin.ibm.com



 ************************REFERENCED NOTE*******************
 | 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
                (4)
             <--------  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
 for.

 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.

 Regards,
 Kurt Chan
 ***********************END OF REFERENCED NOTE************




More information about the T10 mailing list