|
> Immediate commands do not create holes.
True.
> Immediate commands can be aborted ONLY if
referenced by their ITT.
Immediate commands are uniquely identified by
their ITT, not their CmdSN. So yes, an existing immediate command at the target can be
aborted ONLY if the ITT matches the Referenced
Task Tag.
>Again RefCmdSN is used only if the command is
not found by ITT - and then only to avoid having to send a duplicate
command.
>
Julo
It seems that the
implicit assumption that you are making and I am not is that the target will
always find a command with ITT equal to the Referenced Task Tag when the
initiator attempts to abort an immediate command. It follows that if this
were the case, then the target would never use the RefCmdSN improperly.
However, I
do not see any mechanism that guarantees this assumption, especially given the
following three observations:
1) The possible
out-of-order arrival of an abort and the immediate command upon which it is
supposed to act
2) The race between
an immediate command finishing normally (causing the target to free the
command and forget its associated ITT) and the initiator aborting
it
3) The immediate
command to be aborted may have been discarded due to a header digest
error
In the examples I
gave previously, there are several specific situations in which the
assumption does not hold, leading to incorrect behavior of the
target.
Tony
----- Original Message -----
Sent: 30 August, 2002 21:29
Subject: RE: iSCSI: aborting an
immediate command with ABORT TASK
In my example,
the command with the Initiator Task Tag matching the Referenced Task Tag is
not at the target. When the target considers the command with
RefCmdSN received, it assumes _incorrectly_ that the command with RefCmdSN
must have Initiator Task Tag == Referenced Task Tag. That assumption
can be incorrect when immediate commands are used because multiple
commands with different Initiator Task Tags can have the same CmdSN.
This is just another way of looking at the problem, but the problem still
exists.
-----Original
Message-----
From: Julian Satran
[mailto:Julian_Satran@il.ibm.com]
Sent: Friday, August 30, 2002
2:15 PM
To: tonyb@cybernetics.com
Cc: ips@ece.cmu.edu;
owner-ips@ece.cmu.edu
Subject: Re: iSCSI: aborting an immediate
command with ABORT TASK
Tony, As it was already
pointed out CmSN is a SECONDARY identifier - the primary being the
Referenced Task Tag. I was
introduced to simplify handling holes (commands discarded or arriving
late). In your example A and B have
different ITT or one of them gets bumped. Julo
|
| "Tony Battersby"
<tonyb@cybernetics.com>
Sent by: owner-ips@ece.cmu.edu
30/08/02 20:16
Please respond to tonyb
|
To: <ips@ece.cmu.edu>
cc:
Subject:
iSCSI: aborting an immediate command with ABORT TASK
| It seems that an initiator attempting to abort an immediate command
may
inadvertently cause the next non-immediate command to be aborted
instead.
For example,
Initiator sends an immediate command "A"
with CmdSN 10.
Initiator sends a non-immediate command "B" with CmdSN
10.
Initiator sends an immediate ABORT TASK command "C" with CmdSN 11 to
abort
command "A" (RefCmdSN == 10, Referenced Task Tag == Initiator Task
Tag of
"A").
If the target either:
1) Receives "C" before "A"
or "B", OR
2) Receives "C" before "B" but after executing and freeing
"A",
...then the target will not have a matching task for the abort
in its queue,
and will consider CmdSN 10 received because it is inside
the valid CmdSN
window. If the target then receives "B", it will
silently ignore the
command because it is outside the valid CmdSN window.
This is obviously not
what the initiator was trying to
accomplish.
This problem could be solved by adding a flag to the PDU
for the ABORT TASK
command to indicate if the task to be aborted is
immediate or non-immediate.
If the target does not have a matching task
and the RefCmdSN is inside the
valid command window, then the target
should consider the CmdSN received
only if the flag indicates that the
task to be aborted is
non-immediate.
-----------------------
One other thing: for
draft 16, I recommend that the the following phrase:
"... (i.e., with
CmdSN not higher than the task management command CmdSN)
..."
in
section 9.5.1 be changed to:
"... (i.e., with CmdSN lower than the task
management command CmdSN) ...".
This is for consistency with another
sentence earlier in the same paragraph.
Anthony J.
Battersby
Cybernetics
|
