SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: unsolicited Vs immediate; restart delay (fwd)



    
    
    Mallikarjun,
    
    Sorry - I did not see it.
    
    Comments in text.
    
    Julo
    
    
    
    "Mallikarjun C." <cbm@rose.hp.com> on 08/03/2001 20:26:21
    
    Please respond to cbm@rose.hp.com
    
    To:   Julian Satran/Haifa/IBM@IBMIL
    cc:
    Subject:  iSCSI: unsolicited Vs immediate; restart delay (fwd)
    
    
    
    
    Julian,
    
    Did you by any chance respond to this, and I did not get it (I had
    noticed instances of this)?
    
    Or, do I take it that you're going to define a mechanism for the
    missing functionality in the next rev of the draft?
    
    Regards.
    --
    Mallikarjun
    
    
    Mallikarjun Chadalapaka
    Networked Storage Architecture
    Network Storage Solutions Organization
    MS 5668   Hewlett-Packard, Roseville.
    cbm@rose.hp.com
    
    
    Forwarded message:
    
    X-Authentication-Warning: ece.cmu.edu: majordom set sender to
    owner-ips@ece.cmu.edu using -f
    Message-Id: <200103062019.MAA20092@core.rose.hp.com>
    Subject: iSCSI: unsolicited Vs immediate; restart delay
    To: ips@ece.cmu.edu
    Date: Tue, 06 Mar 2001 12:19:17 PST
    Reply-To: cbm@rose.hp.com
    From: "Mallikarjun C." <cbm@rose.hp.com>
    X-Mailer: Elm [revision: 212.4]
    Sender: owner-ips@ece.cmu.edu
    Precedence: bulk
    Status: RO
    
    Julian,
    
    >To:   ips@ece.cmu.edu
    >cc:
    >Subject:  Re: iSCSI: draft04 questions
    >
    >
    >
    >
    >Julian,
    >
    >Thanks.  I am not clear on some. Comments.
    >
    >>2. I didn't find a way for an iSCSI target to say that it does not
    support
    >>any unsolicited data at all.  SPC-2 specifies that a zero FirstBurstSize
    >>means unlimited.
    >>
    >>+++ UseR2T=yes (default) and ImmediateData=no +++
    >
    >I am confused.  I thought this combination disallows just the "immediate"
    >data, and not the unsolicited data as a whole.  The draft hints at this
    >in section 1.2.5.
    >     "A target MAY separately enable immediate data without
    >     enabling the more general (separate data PDUs) form of
    >     unsolicited data."
    >=== for this case you have UseR2T=yes and ImmediateData=yes
    >If I misunderstood, could you please comment how immediate data alone is
    >disabled, while allowing unsolicited data of FirstBurstSize?
    >=== UseR2T=no ImmediateData=no
    
    But that puts the target in unsolicited data mode not requiring R2Ts at
    all!
    
    Sorry if I seem too slow.  Let me try again.  There are three variables -
    
         1. solicited data mode after FirstBurstSize    UseR2T=yes
            unsolicited data mode only                  UseR2T=no
    
         2. Immediate data allowed                      ImmediateData=yes
            Immediate data disallowed                   ImmediateData=no
    
            3. Unsolicited burst (immediate & separate) allowed     ??
               Unsolicited burst not allowed                        ??
    
    FirstBurstSize can be used for (3), but a zero FirstBurstSize means
    "unlimited" than "not allowed".  My original question was how one can
    distinguish the two.
    
    I would be glad to be corrected, if I am misinterpreting the usage of
    UseR2T.
    +++ the confusion stems from the  role of UseR2T.  UseR2T is all about
    allowing an unsolicited first burst.  After the first burst you need always
    R2T.
    You are left now with only 2 parameters controlled by the two variables.
    The only think still open is that for comletness it is probably advisable
    to have for Immediate also a bit in the corresponding mode page bit+++
    +++++++++++++++++++++++++++++++++++++++
    >Do I take it then that the draft currently doesn't specify the maximum
    time
    >the targets should keep the session & connection records around hoping
    >for a restart?  I would strongly recommend adding that as an additional
    >field in the payload, since that is a resource allocation and scalability
    >issue.
    >
    >=== I assume that a traget can figure out by itself after a while that
    >there is no rendezvous - but I am open to requests
    
    There's no architected mechanism to figure out on its own!  Either it
    has to keep the (session, connection, task) states around for a long time,
    OR it can clean up the these states and trigger an unnecessary ULP
    recovery on the initiator which is surprised at an unexpected restart
    failure
    (keep in mind that initiator may not be able to restart a login precisely
    after the "minimum time" specified, typically there's an aggregation
    of multiple O/S timer requests into one master handler).  Providing an
    upper limit is a cleaner, safer design for both initiator and target.
    +++ I will consider it for 06 - no promise though -:) the problem with
    limits of this kind is who's time counts +++
    
    Thanks.
    --
    Mallikarjun
    
    
    Mallikarjun Chadalapaka
    Networked Storage Architecture
    Network Storage Solutions Organization
    MS 5668   Hewlett-Packard, Roseville.
    cbm@rose.hp.com
    
    
    
    
    
    


Home

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