SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: CmdSN during login



    There was ambiguity at first login that we have cleared in text and as I
    said I don't see any good reason
    for another case of immediate when we have the immediate bit available.
    What we could do is add anothe pragraph to 8
    recommending when to use the I bit in login.
    
    Julo
    
    "Eddy Quicksall" <ESQuicksall@hotmail.com> on 10-08-2001 18:13:32
    
    Please respond to "Eddy Quicksall" <ESQuicksall@hotmail.com>
    
    To:   Julian Satran/Haifa/IBM@IBMIL
    cc:   <ips@ece.cmu.edu>
    Subject:  Re: CmdSN during login
    
    
    
    But, what if someone does this without setting the Immediate bit? What
    would
    one do?
    
    What is wrong with just making the CmdSN not run during login? It seems
    like
    it was an arbitrary choice in the first place since it was originally
    optional and not using it actually worked.
    
    If CmdSN is stated as only used in FFP, then I don't see any ambiguity.
    
    Eddy
    ----- Original Message -----
    From: "Julian Satran" <Julian_Satran@il.ibm.com>
    To: <ips@ece.cmu.edu>
    Sent: Friday, August 10, 2001 2:43 AM
    Subject: Re: CmdSN during login
    
    
    >
    > Sanjay,
    >
    > If you want to ignore CmdSN and expedite Login processing you can do so
    by
    > having the commands being issued as immediate.
    > This will help us keep away from creating ambiguity about (or another
    > conditional) for when CmdSN is to be used or not.
    >
    > Julo
    >
    > Mark Bakke <mbakke@cisco.com>@ece.cmu.edu on 09-08-2001 23:55:25
    >
    > Please respond to Mark Bakke <mbakke@cisco.com>
    >
    > Sent by:  owner-ips@ece.cmu.edu
    >
    >
    > To:   Sanjay Goyal <sanjay_goyal@ivivity.com>
    > cc:   "Ips (E-mail)" <ips@ece.cmu.edu>
    > Subject:  Re: CmdSN during login
    >
    >
    >
    >
    > Sanjay-
    >
    > I absolutely agree with this; CmdSN is owned by the session, and
    > should not be used until the connection has fully joined the session,
    > which means full feature phase.
    >
    > This should also clean up any ambiguity on when to start
    > using CmdSN.
    >
    > --
    > Mark
    >
    > Sanjay Goyal wrote:
    > >
    > > Hi
    > >
    > >  Assuming Target and Initiator support multiple connections and the
    > session
    > > is having multiple connections. Assuming out-of-order CmdSN is a
    > possibility
    > > for this session.
    > >
    > >  Connection #   1       |       2       |       3
    > > -------------------------------------------------------
    > > Login Cmd  CmdSN=0      |   CmdSN=8     |  CmdSN=9
    > > Txt   Cmd  CmdSN=1      |               |
    > >                                 |               |
    > >                                 |               |
    > > Login Cmd  CmdSN=7      |  CmdSN=10     |  CmdSN=11
    > > -------------------------------------------------------
    > > Data Cmd   CmdSN=12     | CmdSN=14      | CmdSN=15
    > > Data Cmd   CmdSN=13     |               |
    > >                                 |               |
    > >
    > > CmdSN=7 is last of the Login sequence and it is acknowledged by the
    > Target
    > > with "accept login" response.
    > >
    > > Target would receive the PDUs in this CmdSN order
    > >  0 to 7, 8, 9, 12, 10, 11, 13, 14, 15
    > >
    > > Now as Login and Text PDUs are being processed even though you have
    > received
    > > Data Cmd PDUs, you can not pass them to iSCSI layer and hence you are
    > adding
    > > latency.
    > >
    > > What I want to convey from this example is why not use CmdSN just
    during
    > the
    > > FullFeature phase only.
    > >
    > > Regards
    > > Sanjay Goyal
    > >
    > >
    >
    --------------------------------------------------------------------------
    --------------------------
    >
    > >
    > >    Part 1.2    Type: application/ms-tnef
    > >            Encoding: base64
    >
    > --
    > Mark A. Bakke
    > Cisco Systems
    > mbakke@cisco.com
    > 763.398.1054
    >
    >
    >
    >
    
    
    
    


Home

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