This has become a remarkably complex structure.
FCP took a somewhat simpler approach to the TASK ABORT
synchronization problem.
In FCP, the principal was that the ABORT TASK chase
the targeted command through the chain of host
adapter,
transport media, target/logical unit, and
back again, clearing
up whatever residues were
encountered along the way.
That way, ordering was never an issue, because the
command
was either completed before an ABORT TASK ever
started, or
the ABORT TASK tracked it down and aborted
the artifacts
associated with the command wherever
they were found. The
inclusion of the HBA in the
chain eliminated any possibility
of the command
escaping after the ABORT TASK was transmitted.
It also
eliminated ordering issues associated with transport
paths, since any residue left in the transport path was
deprived of context and discarded if it popped out
later.
Bob
> -----Original Message-----
>
From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com]
> Sent: Thursday, September 05, 2002 7:51 AM
> To: 'Paul Koning'
> Cc:
Black_David@emc.com; ips@ece.cmu.edu
> Subject: RE:
iSCSI: aborting an immediate command with ABORT TASK
>
>
>
Paul,
>
> Its a race
having to do with sending the command response and
> receiving the
> abort ... not between
getting the command and the abort request.
>
> I-T> immediate cmdSN=7
> T-I> some delay but finally command response for above
w/ExpCmdSN=7
> (a race here due to processing at
the initiator)
> I-T> before getting the
response, sends abort for 7
> (target advances
ExpCmdSN to 8)
> I-T> non-immediate
CmdSN=7
> (outside of the command window, target
dumps the command)
>
>
The directions say to consider the command received (that
> would mean the
> non-immediate command)
and that would be command 7. So you
> would
advance
> ExpCmdSN to 8. When non-immediate command
7 arrives, it will
> be outside of
> the window and will be thrown out.
>
> This is all considering ErrorRecoveryLevel
0.
>
> Maybe I have
missed something so please point out where I'm wrong.
>
> Eddy
>
> -----Original Message-----
> From: Paul Koning [mailto:ni1d@arrl.net]
> Sent: Thursday, September 05, 2002 9:49 AM
> To: Julian_Satran@il.ibm.com
> Cc:
Black_David@emc.com; ips@ece.cmu.edu
> Subject: RE:
iSCSI: aborting an immediate command with ABORT TASK
>
>
>
>>>>> "Julian" == Julian Satran
<Julian_Satran@il.ibm.com> writes:
>
> Julian> The next command can't be
clobered. Abort Task acts on
> Julian>
command up to 6 (included) but not 7- and it has to be on the
> Julian> same connection as the aborted command. That
insures that it
> Julian> will abort the
first immediate but not the non-immediate
>
Julian> after.
>
> If
the abort has to be sent on the same connection as the command
> being aborted, then it cannot overtake an immediate
command preceding
> it. At least not in the
network stack... So that seems to eliminate
>
the case that David was worrying about.
>
> paul
>
