SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI - Change Proposal X bit



    That is an interesting proposal. However since it won't work in face of an 
    initiator that does not actively use the connection (your two prameters 
    are per/session values determined by the initiator.
    
    I read Mallikarjun's proposal to add a stricter requirement on activity 
    and thus avoid cleaning NOPs - as "send some non-immediate request that 
    requires a response on every connection at least once in 2^31-1 CmdSN  to 
    include anything sent (no additional traffic).
    
    I intended to something close to your rule at the target to avoid 
    increasing the window into the "dangerous zone" while not requiring a 
    synchronous barrier at the initiator.
    
    Julo
    
    
    
    
    sandeepj@research.bell-labs.com (Sandeep Joshi)
    Sent by: owner-ips@ece.cmu.edu
    27-10-01 03:08
    Please respond to sandeepj
    
     
            To:     cbm@rose.hp.com, ips@ece.cmu.edu
            cc: 
            Subject:        Re: iSCSI - Change Proposal X bit
    
     
    
    Mallikarjun,
    
    This problem can be solved _without_ introducing
    any additional I/O activity.   Notice that it 
    occurs because we allow the maxCmdSN to increase 
    unbounded in the presence of unacked statSNs.
    
    The target can prevent this from happening.
    
    Imagine some connection A at the target :
    
    (1) Everytime the target sends a new statSN out, it 
        records the cmdSN for that statSN 
        (say Connection_A.cmdSN_of_last_statSN = 200)
    
    (2) While growing maxCmdSN at target, ensure that
        (maxCmdSN - Connection_A.cmdSN_of_last_statSN < 2^31-1)
    
        This is stricter than current condition
        (maxCmdSN - expCmdSN) < 2^31-1
    
        If there are N connections, use least value of 
        cmdSN_of_last_statSN.
    
    (3) All retried commands will always fall outside 
                     the window.  They will be on the "dark side".
    
    (4) If the target cant grow maxCmdSN, it closes the
        offending connection, or sends out NOPs.
    
    Works ..?
    
    -Sandeep
    
    
    > In helping others walk through your scenario here in HP,
    > we all realized that the core solution to the problem
    > is to mandate a complete execution of a numbered command
    > (some I/O activity that is trackable) on each connection
    > once at least every (2^32 -1) commands.  It may be a NOP,
    > or any regular command.  So, here is my suggestion -
    > 
    >   An initiator MUST send at least one non-immediate command
    >   on each of the connections participating in the session,
    >   for every (2^31 -1) numbered commands.
    > 
    > Comments?
    > --
    > Mallikarjun 
    
    
    
    
    
    


Home

Last updated: Sun Oct 28 16:17:42 2001
7431 messages in chronological order