SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: CmdSN during login



    Sounds like a good idea to me, and this would also lead to
    a definitive resolution of the resource allocation requirements
    at targets for immediate commands (which I believe is still
    an open issue).  Providing both options just adds complexity,
    and I have seen no requests for logins on connections other
    than the first to be ordered with respect to other commands
    on the first connection.
    
    Thanks,
    --David
    
    ---------------------------------------------------
    David L. Black, Senior Technologist
    EMC Corporation, 42 South St., Hopkinton, MA  01748
    +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
    black_david@emc.com       Mobile: +1 (978) 394-7754
    ---------------------------------------------------
    
    
    > -----Original Message-----
    > From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
    > [mailto:matthew_burbridge@hp.com]
    > Sent: Monday, August 13, 2001 12:35 PM
    > To: ips@ece.cmu.edu
    > Subject: RE: CmdSN during login
    > 
    > 
    > Could commands sent during the login phase (ie LOGIN + TEXT) 
    > be mandatory to
    > be immediate and therefore MUST have the I bit set or is 
    > there a reason why
    > non-immediate login phase commands make sense?
    > 
    > Cheers
    > 
    > Matthew Burbridge
    > 
    > -----Original Message-----
    > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
    > Sent: Saturday, August 11, 2001 4:37 PM
    > To: ips@ece.cmu.edu
    > Subject: 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