SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: Avoiding deadlock in iSCSI


    • To: ips@ece.cmu.edu
    • Subject: RE: Avoiding deadlock in iSCSI
    • From: Pierre Labat <pierre_labat@hp.com>
    • Date: Wed, 13 Sep 2000 01:48:58 -0700
    • Content-Transfer-Encoding: 7bit
    • Content-Type: text/plain; charset=us-ascii
    • Organization: Hewlett Packard ATM-SISL
    • Sender: owner-ips@ece.cmu.edu

    From the discussion going on the symmetric versus asymmetric model and
    dead lock avoidance, here is  a proposal that tries to combine (as far
    as possible...)
    the advantages of both models.
    
    The proposal is a slightly modified symmetric model where
    the symmetric model incorporate an idea of the current
    asymmetric model.
    
    This idea is that the initiator indicates to the target
    on which connection the next command in order arrives.
    The asymmetric model does that using an extra connection
    transporting the commands, and for each command in the header
    there is the connection number where the data will come.
    
    
    Description of the proposal:
    ---------------------
    In the command header a field is added. This field
    "next connection" indicates the TCP connection (connection id)
    in the session on which the next command will arrive.
    This field builds a linked list of commands across the several
    symmetric connections of the session.
    
    The first time the initiator posts a command, it determines
    the connection on which it post the command and the connection
    on which it will post the next command.
    Then for each command the initiator determines only
    the connection it will use to post the next command.
    For each command, the connexion id of the next command is added in the
    header
    field "next connection" of each command.
    
    
    Doing that, leads to the same algorithm as in the asymmetric model
    to process the commands on the target side:
    - a thread of execution pulls the cmd/data in order from the TCP
      windows. After pulling a cmd/data, it looks at the "next connection"
      field and move to the next connection to pull a new cmd/data.
      There is no need of extra storage out of the TCP windows
      and no need to re-order. In the asymmetric model the thread
      empties the command connection, here it follows the chain of commands.
    
    The advantage of this proposal are:
    - on the target, as opposed to the original symmetric model, it avoids
      the re-ordering process of the commands once extracted
      off the TCP window.
    - it keeps cmd/data/status on a same connexion avoiding
      the synchronization penalty for the READS on the initiator (described
      by Somesh Gupta)
    - it saves one TCP connection compared to the asymmetric model.
    
    
    Anyway any ordering implementation adds overhead, thus, as in most
    cases (disks) it is not required, It would be possible to deactivate it.
    
    
    
    Regards,
    
    Pierre
    
    


Home

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