SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: Task Management Commands and Immediate Delivery.



    Thanks,  I had missed the fact that the barrier list was only Task
    Management commands.  The algorithm works much better with that
    understanding!  (next time I'll read a little closer...)
    
    
    Charles Binford
    Pirus Networks
    316.315.0382 x222
    
    
    -----Original Message-----
    From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
    [mailto:matthew_burbridge@hp.com]
    Sent: Tuesday, June 12, 2001 9:21 AM
    To: 'Binford, Charles'
    Subject: RE: Task Management Commands and Immediate Delivery.
    
    
    Hi Charles,
    
    Comments within text:
    
    Matthew
    
    -----Original Message-----
    From: Binford, Charles [mailto:CBinford@Pirus.com]
    Sent: Tuesday, June 12, 2001 2:50 PM
    To: 'BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)'; 'ips@ece.cmu.edu'
    Subject: RE: Task Management Commands and Immediate Delivery.
    
    
    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
                     -->
    ***Matthew:  The abort will have the CmdSN field set to 11 (to mark its
    position).
    
    
    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.  
    
    ***Matthew: The barrier list contains only the TM commands.  In your example
    the barrier list will contain the immediate command (e.g. CmdSN=11).  The
    commands (and placeholders) are marked for candidacy.
    
    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.
    
    ***Matthew: You are right.  In this example CmdSN has been delivered to the
    SCSI layer (within the target) and that resulted in the ExpCmdSN being
    incremented.  The TM command must be passed to the SCSI layer and it is the
    SCSI layer that would abort CmdSN=8.
    
    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?
    
    ***Matthew: The Task Management commands are the only ones that effect other
    commands and hence the reason for this algorithm.
    
    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
    


Home

Last updated: Tue Sep 04 01:04:31 2001
6315 messages in chronological order