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



    Sandeep,
    
    Okay, it seems we are beginning to agree with each other.
    
    Please note that my suggestion to mandate at least one non-immediate
    command every 2^31 -1 commands does not preclude a double-check
    by a target in an implementation.  It would be no different from an
    initiator
    implementation double-checking that a target is giving no more than a
    (mandatory limit of) 2^31 -1 credit (both are protocol violations).  That
    said, I tend to differ on your idea of who the "victim" would be if this
    proposed protocol requirement is not adhered to.  If initiator does not
    follow
    the proposed stipulation, it gets what it deserves - a possible data
    corruption.
    But perhaps this view is slightly subjective.
    
    Finally, CmdSN as the name indicates is a sequencing mechanism.  We
    have studiously avoided so far to use CmdSN beyond sequencing, and
    relied on ITT as the identifier for (an instantiated) task.
    
    Regards.
    --
    Mallikarjun
    
    Mallikarjun Chadalapaka
    Networked Storage Architecture
    Network Storage Solutions Organization
    MS 5668 Hewlett-Packard, Roseville.
    cbm@rose.hp.com
    
    ----- Original Message -----
    From: "Sandeep Joshi" <sandeepj@research.bell-labs.com>
    To: <cbm@rose.hp.com>
    Cc: "ips" <ips@ece.cmu.edu>
    Sent: Saturday, October 27, 2001 9:50 AM
    Subject: Re: iSCSI - Change Proposal X bit
    
    
    >
    >
    > Your 2nd argument make sense..the first seems like a
    > issue of changing the cmdSN definition.   That said,
    > I'd rather have preventive measures to make the target
    > protect itself rather than assume the initiator sends
    > out certain periodic messages.
    >
    > -Sandeep
    >
    > "Mallikarjun C." wrote:
    > >
    > > Sandeep,
    > >
    > > >because we allow the maxCmdSN to increase
    > > > unbounded in the presence of unacked statSNs.
    > >
    > > That's true!  Two concerns -
    > >
    > > - We have been using CmdSN at the target only
    > >   for reordering of commands, and it becomes irrelevant
    > >   once a SCSI task is instantiated (section 2.2.2.1).
    > >   Your suggestion doesn't appear to conform to this
    > >   idea - in fact it seems to require CmdSN association
    > >   beyond the task conclusion.
    > >
    > > - CmdSN credit management is an iSCSI session activity,
    > >   and tying session level credit management with StatSN
    > >   ACKs that happen at a connection level doesn't seem to
    > >   enable a clean "session manager" separation spanning
    > >   multiple NICs.
    > > --
    > > Mallikarjun
    > >
    > > Mallikarjun Chadalapaka
    > > Networked Storage Architecture
    > > Network Storage Solutions Organization
    > > MS 5668 Hewlett-Packard, Roseville.
    > > cbm@rose.hp.com
    > >
    > > Sandeep Joshi wrote:
    > > >
    > > > 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: Sat Oct 27 17:17:43 2001
7427 messages in chronological order