RE: iSCSI: R2T/ABORT_TASK interaction

[Eddy Quicksall <Eddy_Quicksall@ivivity.com>]

Here is my initial thinking ---

The initiator must not make any assumptions about timing of the abort. There
are other cases similar to what you have pointed out (such as the status is
on its way back at the time the abort begins).

The target also has internal race conditions of its own and its code must
also take that into account (such as the command is being completed by a
lower layer or HBA at the same time it is issuing an abort to the lower
layer or HBA).

Now, since anything can go wrong that causes the need for the abort, both
parties are already in a position to recover. So, if the initiator does or
does not respond to the R2T, the target should be able to cope (even if the
response comes to the target after the target has already sent the TMF
response or started the abort).

One thing is for sure, the initiator should not respond to the R2T after it
has received the TMF response. 

Eddy

-----Original Message-----
From: Pittman, Joseph [mailto:Joseph.Pittman@netapp.com]
Sent: Tuesday, February 05, 2002 4:01 PM
To: 'IPS Reflector'
Subject: iSCSI: R2T/ABORT_TASK interaction

Can anyone describe the required behavior of an initiator under
the following condition?  This may be a basic SCSI-3 question
rather than iSCSI specific; if so, I apologize, but still ask
for guidance.

Suppose an initiator submits a SCSI Command PDU containing a large
SCSI write operation (where large means >= FirstBurstSize).
Before the initiator receives an R2T for the first (or next)
chunk of the data, the initiator decides to abort the task with
an ABORT_TASK (or other) Task Management PDU.

In the meantime, the target has prepared its buffers and submits
the R2T.  The R2T and the ABORT_TASK PDUs 'cross paths':

  Time     Initiator                          Target
    |
  0 |      SCSI_CMD ---------\
    |                         \-------------->
    |
    |      ABORT_TASK ------\
    |                        \   /------------- R2T
    |                         \ /
    |                          X------------->
    |                         /
    |                <-------/
  T |
    V

At time T, the target has received an ABORT_TASK for the SCSI
command, but has already sent an R2T.  The initiator has
just received an R2T for a SCSI task which it is trying to
abort.  The target has not yet sent a response to the ABORT_TASK
task management command.

The question is this: what are the responsibilities of the
initiator and target at this point?

- Is the initiator required or expected to respond to the
  R2T, perhaps with a zero-length DATA_OUT PDU?

- Is the target expected to wait for the initiator to respond
  before aborting the task?  Or is the initiator allowed (or
  required) to go ahead and abort the task and send the task
  management response, without waiting for any DATA_OUT, then
  silently discard any R2T it might receive later?


Thanks in advance for any help.
--
Joe Pittman
jpittman@netapp.com