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
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
This may be the only reliable method for class 3 anyway.
gfrazier at austin.ibm.com
| 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 --------->
<-------- XFR_RDY <-------- Data
Data ---------> <-------- Data
Data ---------> <-------- 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
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
***********************END OF REFERENCED NOTE************
More information about the T10