SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: Out Of Sequence due to null sequence with multiple con nections.



    
    
    CmdSN is meant to be short lived.  Commands numbers are not retained after
    command start executing.  However you would like to have a task management
    command operating on task executing.
    
    Julo
    
    sandeepj@research.bell-labs.com (Sandeep Joshi) on 06/04/2001 05:47:59
    
    Please respond to sandeepj@research.bell-labs.com (Sandeep Joshi)
    
    To:   ips@ece.cmu.edu
    cc:
    Subject:  RE: iSCSI: Out Of Sequence due to null sequence with multiple con
          nections.
    
    
    
    
    > Unfortunately, I think we have an impossible situation.  It appears to me
    > that
    > we have to pick at most two of the following three goals, as I have yet
    to
    > see
    > any way to achieve all three for a single task management command on a
    > multiple connection session:
    >
    > (1) The command takes effect immediately and its status/response
    >         is available immediately.
    > (2) The command affects all commands in flight, and its status/response
    >        is delayed until all such effects are complete.
    > (3) There is no significant visible departure from existing SCSI task
    >        management behavior.
    > ...
    > ...
    > Sandeep's proposal to create state in the target either fails to achieve
    > (1) [if the response is delayed until the state is removed] or violates
    SAM2
    > [returns the response to the task management command before the task
    > management command is complete].  Having state linger after a completed
    > LUN or TARGET RESET is almost certainly wrong.
    
    Hi David,
    
    Still wading thru related emails but I believe that if a refCmdSN
    is added to the task management PDU (not present currently but
    could be added for task-related management commands), then it
    might fix the above-mentioned flaws and allow for safe execution
    and immediate delivery of the abort task to the target.
    
    refCmdSN (cmdSN of refTaskTag) can tell you where the abort task
    command was received in the target command stream.
    
    Processing at target :
    1) Initiator task tag reuse : should not happen before refCmdSN
       so can be used for comparisons until refCmdSN expires.
    2) State deletion : can be done by target after refCmdSN PDU
       has arrived and is processed/dropped.
    3) If Abort task command is early (refCmdSN not arrived) :
       then create state and drop PDUs when they arrive.
    4) If Abort task command is Late (executing now beyond refCmdSN):
       target sends a task response of task-not-found (this return
       code exists in the draft).   Otherwise, we may cancel the
       wrong task if the initiator task tag has been reused!
    5) If Abort task reaches when target is executing refCmdSN :
       pass abort task to SCSI layer and return response.
    6) Task response can be returned as appropriate to conform with
       SAM2 - either after in-flight commands arrive or immediately
       since the target knows what needs to be done later.  I am slightly
       confused here since your goals (1)&(2) appear to be contradictory
       for application to in-flight commands.. it depends on semantics
       what "taking effect" implies ?
    
    One question is, is it reasonable to assume that the initiator
    knows the cmdSN of an issued original task(cmdSN<->initiator taskTag).
    This knowledge may be anyway needed if commands are to be re-issued
    in cmdSN order during recovery of a broken connection.  Its an
    implementation issue but can be debated.
    
    Any other holes that we see..
    1) multi-NIC initiators ?
    2) dont want to introduce state at target ?
    3) may affect iSCSI routers or gateways in strange ways ?
    4) linked command issues ?
    
    thanks,
    -Sandeep
    
    
    
    


Home

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