RE: iSCSI: Logical Unit Reset

["Tony Battersby" <tonyb@cybernetics.com>]

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Bill Studenmund
> Sent: Tuesday, October 08, 2002 8:22 PM
> To: Tony Battersby
> Cc: 'Eddy Quicksall'; ips@ece.cmu.edu
> Subject: RE: iSCSI: Logical Unit Reset

> I'm confused. I thought what Eddie was talking about is the
> case where we
> have two initiators (well two sessions). One of them issues
> some commands.
> The other does a LU reset, wiping out those commands. Then
> the first comes
> along and does a task management request on the original
> commands, which
> aren't there anymore because the other session did a reset
> (and thus the
> Task Management command can't work on them).
>
> Or is that not what Eddie was talking about?
>
> Take care,
>
> Bill

I can't speak for Eddy, but to me this sounds like a slightly different but
related question.  Let me try to illustrate what I think should happen with
an example:

Suppose that two initiators, I1 and I2, have open sessions with the same
target.  Initiator I1 has an outstanding NOP-Out and an outstanding SCSI
command, and is waiting for a reply to both.  Initiator I2 also has an
outstanding NOP-Out and an outstanding SCSI command, and is waiting for a
reply to both.  At this point, initiator I1 issues a Logical Unit Reset.
The question is, what specifically happens to the four outstanding commands
(the two SCSI commands and the two NOP-In replies to the two NOP-Outs).

In section 9.5.1: "The iSCSI target MUST ensure that no responses for the
tasks covered by a task management function are delivered to the iSCSI
initiator after the Task Management response except for a task covered by a
TASK REASSIGN."  The use of the definite article "the" in the phrase "the
iSCSI initiator" implies that this sentence applies only to the initiator
that issued the TMF, and not to any other initiator.  For initiator I1, the
following sequences of events are valid for the target:

1) Return both the NOP-In and the normal response to the SCSI command
completing, followed by the TMF response.
2) Return only the NOP-In, followed by the TMF response.  Never return the
SCSI command response.
3) Return only the normal response to the SCSI command completing, followed
by the TMF response.  Never return the NOP-In.
4) Return the TMF response.  Never return the SCSI command response or the
NOP-In.

By "normal response to the SCSI command", I mean the response that would
have been returned had there not been a Logical Unit Reset.  Which sequence
of events is taken depends on the implementation and timings at the target.

The iSCSI draft doesn't say anything about what should happen to the
commands from initiator I2, so I assume that nothing should happen to them
except as specified by SAM-2 section 5.7.3 ("When a SCSI initiator port
aborts tasks from other SCSI initiator ports").  The NOP-In from initiator
I2 should not be affected at all, since the SCSI layer doesn't know about
it.  So basically, the Logical Unit reset from initiator I1 alters the SCSI
command response for the SCSI command from initiator I2, but it doesn't make
any tasks from initiator I2 suddenly disappear from the target.

So, to finally respond to your question, the assumption that the commands
"aren't there anymore because the other session did a reset" is incorrect
because the command _are_ still there.  After the LU Reset, the target is
still intending to return a response to both the NOP-Out and the SCSI
command from initiator I2.  The LU Reset from initiator I1 _has_ changed the
SCSI command response for the SCSI command from initiator I2, but has not
affected the commands from initiator I2 in any other way.

Anthony J. Battersby
Cybernetics