RE: Task Management Commands and Immediate Delivery.

["Binford, Charles" <CBinford@pirus.com>]

Matthew,  In the portion of text I copied from your attachment, step b)
claims to know that the removed entries had been aborted by the target in
the target's iSCSI layer.  
----------------------------------
      At the initiator when updating ExpCmdSN: 
       
         a) if the "barrier list" is empty or ExpCmdSN is less than the
            CmdSN of the oldest item in the barrier list then skip to
            step d 
         b) remove the oldest barrier list item, and remove and silently
            discard all entries marked for cleanup having a CmdSN field
            less than ExpCmdSN.  These entries have been aborted by the
            target while they were in the target's iSCSI layer. 
-----------------------------------

I don't see how the initiator can know that.  Consider the following
scenario:

Imitator            Target
CmdSn 8  ---> -_
                 -->  
CmdSn 9  ---> -_    <-- expCmd 9
                --> 
CmdSn 10 ---> -_    <-- expCmd 10
                -->
Abort (imm)--> -_   <-- expCmd 11
                 -->

Assume at that at the time the Abort was sent, the expCmd 9 had not yet
arrived (hard to show in ASCII drawings!)  When the initiator sent the
abort, he created the barrier list of Cmdsn 8-10.  

When expCmd 9 arrives at the initiator, the processing will take him to step
b) above and remove that task associated with CmdSn 8.  However, since the
Abort had not yet arrived at that target when the target sent expCmd 9,
CmdSn 8 was certainly not aborted by the target's iSCSI layer.

I've been trying to figure out if the offending sentence is merely an
non-significant, incorrect statement on what happens or if it is a hole in
the algorithm.  On the other hand, maybe the statement and algorithm are
correct and I miss-understood something.

Also, this algorithm has an unspoken assumption that only task management
functions will be delivered with the immediate option.  Don't things break
down if an initiator chooses to send normal SCSI I/O with immediate?

Charles Binford
Pirus Networks
316.315.0382 x222


-----Original Message-----
From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
[mailto:matthew_burbridge@hp.com]
Sent: Monday, June 11, 2001 12:08 PM
To: 'ips@ece.cmu.edu'
Subject: Task Management Commands and Immediate Delivery.


We have been working through section 7.3 and were unclear on a few areas.
Essentially, the algorithm is fine but we felt that there were are number of
areas that either need clarifying or expanding.

Attached is an 'updated' version of the section that addresses the issues.

The algorithm relies on both the initiator and target performing the exact
same action to remove items off of the command queues otherwise there could
be either a discrepancy between the two sides.  Another alternative is for
the target to inform the initiator of those commands that have been aborted
in the iSCSI layer (but not the SCSI layer).  In which case there is no need
to implement the algorithm in the initiator.

Matthew Burbridge
NIS-Bristol
Hewlett Packard
Telnet: 312 7010
E-mail: matthewb@bri.hp.com