RE: iSCSI: aborting an immediate command with ABORT TASK

[Eddy Quicksall <eddy_quicksall@ivivity.com>]

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