SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iscsi : default iscsi mode page settings.



    Hello John I agree with you completely.
    
    The confusion going over here is that the Buffer/Cache manager that you are
    dscribing below is being thought over as a part of SCSI realm but i donot
    agree with that. Specially the line from Julian "It looks to me that
    association of sink buffers at targets is mostly a SCSI issue and it is
    dependent on the device type,"
    
    It is not at all a SCSI issue. An iSCSI target has to bring in the data in
    proper order so that it can be transferred into LU properly. The only
    association that can be thought of with a SCSI layer is that relative speed
    of transfer of data from network and the transfer speed of data from SCSI
    bus to SCSI device. If that is considered any sort of association then it is
    an association of both the transport layer and SCSI Bus.
    
    The reason I suggested to put all the SCSI Mode page parameter into login
    keys is that the iSCSI target doesnt have to scan the commands lying within.
    It doesnt have to poll whether a mode select command is going or not?? This
    will make the implementation of the box described below by you much easier.
    However if we think of a complete SCSI target which has box and SCSI built
    in will not have to face this problem.
    
    I would like to know the reasoning as to why is it not better to keep all
    the SCSI mode page parameters not as login keys. The two main benefits of
    putting FirstBurstSize only into login keys  are the following
    
    1. the the initiator will have to make one command less to target during
    login operation( it will not have to do any mode sense)
    2. no snooping of command by black box implementation
    
    if we put all other mode page parameters into login keys they will benefit
    from both the above two things and it is also important to note that putting
    alone Firstburstsize into login keys will not make any command less because
    the initiator anyway has to make a mode sense commannd for other parameters
    of SCSI mode page.
    
    Thanks,
    Sanjeev
    
    
    
    
    -----Original Message-----
    From: John Hufferd [mailto:hufferd@us.ibm.com]
    Sent: Tuesday, September 25, 2001 7:54 PM
    To: Julian Satran
    Cc: ips@ece.cmu.edu
    Subject: Re: iscsi : default iscsi mode page settings.
    
    
    
    Julian.
    Thank you for taking the time to express your views, in this way.  That
    type of dialog can help push the debate forward.
    
    Now let me expressed some views that I hold, and ask you to let me know
    where I am wrong.
    
    I have viewed the Buffer/Cache Manager as an independent entity that
    belongs to the "Box" (or the embedded OS).  I have not viewed the
    Buffer/Cache Manager as being a SCSI entity.  Instead I have viewed SCSI as
    a user of the Box services called Buffer/Cache Manager.
    
    Likewise, I have viewed the Transport as a user of this same Buffer/Cache
    Manager(B/CM).
    
    I can understand that the B/CM can have certain input and output flows that
    it needs to be designed to handle.  Further I understand that part of that
    design should factor in the needs of the SCSI LUs to consume Buffer Space.
    But the requirements of the Transport also needs to be factored in.
    
    As a result, I expect that there needs to be some defaults per link, and if
    the Transport is to negotiate Burst values, there probably needs to be an
    interface with the B/CM to ensure that the right values are negotiated.
    
    However, it is not clear that it makes sense for the iSCSI layer to keep
    polling (interfacing to) the B/CM just in case a SCSI command has changed
    the Mode Pages, nor does it see reasonable for iSCSI to inspect the CDBs to
    see if its mode Page items are being changed.
    
    So if it is not affected by a SCSI command and is only handled with
    Login/Text Command, then an approprate interface between the B/CM can be
    used to query about the approprate values to negotiate at any specific
    time.  I think this is a reasonable and approprate design.
    
    This is why I have come to the conclusion that the burst values (other then
    defaults, if any) should not be a Mode Page item.
    
    Now it is clearly possible that I have missed something important here, so
    please let me know what it is.
    
    .
    .
    .
    John L. Hufferd
    Senior Technical Staff Member (STSM)
    IBM/SSG San Jose Ca
    Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
    Home Office (408) 997-6136
    Internet address: hufferd@us.ibm.com
    
    
    Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/24/2001 11:28:15 PM
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   ips@ece.cmu.edu
    cc:
    Subject:  Re: iscsi : default iscsi mode page settings.
    
    
    
    
    Sanjeev,
    
    We can set any of those parameters wherever you want as its clearly a
    protocol prerogative.
    The one thing that I am trying to avoid is having one parameter being
    handled in two ways (It caused me more trouble that it was worth in the
    past and required a lot of logic).
    As such we have two consideration when selecting location:
    
       legacy
       what layer is the most affected by it
    
    It looks to me that association of sink buffers at targets is mostly a SCSI
    issue and it is dependent on the device type,  the relative speed of the
    transport and device, QOS requirements at device.  Data is already in the
    SCSI realm (not anymore individual PDUs but sequences that are governed by
    SCSI needs and (including fairness rules between LUs attached to the same
    bus). That is why we have those bursts - iSCSI does not need them - SCSI
    may need them for multiplexing and buffer limitations of its own.   As far
    as iSCSI is concerned bursts are just trouble.  But without them a pipe
    with a limited window will serve one LU and even beyond it's real
    capabilites.   The multiplexing capability is needed by SCSI and is offered
    in different ways on different transports. Some "buses" have a "built-in"
    multiplexing capability. TCP does not and iSCSI adds it to it by the "burst
    limitation".
    
    All this said and based on an earlier comment made by Bob Snively that this
    could be a good criteria for splitting parameters between text and mode
    pages - I think that the split we have now, even if not built according to
    every developers wet dreams, is reasonable.
    
    Julo
    
    
    
    
                        "Sanjeev Bhagat
                        \(TRIPACE/Zoetermee       To:     "Santosh Rao"
    <santoshr@cup.hp.com>, John
                        r\)"                       Hufferd/San Jose/IBM@IBMUS
                        <iscsi_t10@sanjeevb       cc:     Julian
    Satran/Haifa/IBM@IBMIL,
                        hagat.com>                 <ips@ece.cmu.edu>
                                                  Subject:     Re: iscsi :
    default iscsi mode page
                        25-09-01 01:58             settings.
                        Please respond to
                        "Sanjeev Bhagat
                        \(TRIPACE/Zoetermee
                        r\)"
    
    
    
    
    
    Julian, Santosh,
    
    Can we make all the SCSI mode page paramters be made as login keys? Why
    should they be kept in a seperate mode page at all??
    
    Sanjeev
    ----- Original Message -----
    From: "John Hufferd" <hufferd@us.ibm.com>
    To: "Santosh Rao" <santoshr@cup.hp.com>
    Cc: "Julian Satran" <Julian_Satran@il.ibm.com>; <ips@ece.cmu.edu>
    Sent: Monday, September 24, 2001 10:34 PM
    Subject: Re: iscsi : default iscsi mode page settings.
    
    
    >
    > In addition to what Santosh said,  If I understand this right,
    > I think it is a problem for iSCSI to have to keep going across layers to
    > determine what the values are.  Since iSCSI Target will not see the CDB
    > that caused the values to change.
    >
    > Now if the value in the mode page is only the default, that would be a
    > different issue.
    >
    > .
    > .
    > .
    > John L. Hufferd
    > Senior Technical Staff Member (STSM)
    > IBM/SSG San Jose Ca
    > Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
    > Home Office (408) 997-6136
    > Internet address: hufferd@us.ibm.com
    >
    >
    > Santosh Rao <santoshr@cup.hp.com>@ece.cmu.edu on 09/24/2001 12:28:43 PM
    >
    > Sent by:  owner-ips@ece.cmu.edu
    >
    >
    > To:   Julian Satran/Haifa/IBM@IBMIL
    > cc:   ips@ece.cmu.edu
    > Subject:  Re: iscsi : default iscsi mode page settings.
    >
    >
    >
    > Julian Satran wrote:
    >
    > > I can sympathize with you wanting to use most of the parameters in
    iSCSI
    > -
    > > but the values are in fact restrictions that SCSI places on iSCSI.
    >
    > Julian,
    >
    > I'm confused by your response.
    >
    > The SPC-2 description of Disconnect-Reconnect mode page indicates that :
    > "The parameters appropriate to each protocol and their interpretation for
    > that protocol may
    > be specified in the individual protocol documents".
    >
    > FYI, SPI[-4] has chosen not to attach any semantics to FirstBurstSize for
    > the pSCSI
    > transport. Thus, iscsi is within its rights to declare this field as
    > reserved and attach no
    > meaning to it in the mode page. The FirstBurstSize can be negotiated
    during
    > iscsi login
    > through a login key.
    >
    >
    > > Nevertheless the discussion is rather academic because SCSI can hand
    > those
    > > parameters to iSCSI.
    >
    > Again, I'm confused by your response. The reasons I'm suggesting the use
    of
    > a login key
    > instead of the mode page method are :
    >
    >    * More accurate scope (applies only to this I-T nexus).
    >
    >    * More optimal negotiation and reduced overhead in the establishment
    of
    > the I-T nexus. (2
    >      less SCSI commands per I-T nexus establishment.).
    >
    >    * Enables faster I/O scan times due to lesser on-the-wire activity
    > during I-T nexus
    >      establishment.
    >
    >    * Allows less room for error in the I-T nexus establishment (no
    > possiblity of failure to
    >      establish I-T nexus due to mode sense/select command failure).
    >
    >    * Avoids mode select wars that can occur when target uses shared mode
    > pages.
    >
    >    * Simpler initiator implementations since they can avoid embedding
    SCSI
    > command set
    >      knowledge as well as code to build/parse SCSI commands. Also, they
    can
    > avoid extra code
    >      that is required to snoop for CHECK CONDITION with (sense key=UA,
    ASC
    > ="mode parameters
    >      changed") in order to re-issue a mode sense to determine new values
    > for FirstBurstSize.
    >
    >    * Less code to interact with SCSI ULP application client to
    co-ordinate
    > the mode page
    >      values b/n the ULP & LLP.
    >
    >    * Can use un-solicited data from the very first scsi command in the
    > session.
    >
    > I don't consider any of the above reasons to be academic and would like
    to
    > know which ones
    > among the above do you believe are academic and why ?
    >
    >
    > > SCSI can handle those parameters dynamically. iSCSI may have trouble
    > > handling this type of negotiation dynamically over several connections.
    >
    > This is exactly the kind of stuff we don't need and should actually be
    > trying to avoid. What
    > good does dynamically changing FirstBurstSize serve ? Dynamically
    changing
    > FirstBurstSize
    > would only be achieved with least side-effects if :
    > 1) The mode select implementation on target is not using shared mode
    pages.
    > 2) The initiator has quiesced I/O prior to issuing the mode select for
    the
    > change.
    >
    > Neither of the above 2 conditions would typically apply and any dynamic
    > change of
    > FirstBurstSize would only cause initiators to see a bunch of side-effects
    > such as :
    > a) Active outbound I/Os aborted by the target with a CHECK CONDITION due
    to
    > "not enough
    > un-solicited data".
    > b) UA CHECK CONDITION for "mode parameters changed".
    >
    > In the interests of simplification and avoiding disruption of active I/O,
    > such modifications
    > must be avoided as far as possible. One way to achieve that is to use a
    > login key and make
    > it LO.
    >
    >
    > >
    > > Resource-wise (as Bob Snively has pointed out) those are SCSI issues.
    > >
    > > A nice way out would be to ask T10 for a text mode negotiaton :-)
    >
    > Once again, I'm perplexed by your response. I'm not saying that text mode
    > negotiation is the
    > reason I suggest moving this to a login key. The main objective is to
    > isolate such
    > negotiation within the iscsi layer in an iscsi specific PDU that is a
    part
    > of the iscsi
    > login process.
    >
    > Hope you will consider all of the above factors.
    >
    > Thanks,
    > Santosh
    >
    > ps : [I wonder if there are any others on this list who care to voice
    their
    > opinion on this
    > issue. (??). ]
    >
    >
    >
    >
    >
    >
    
    
    
    
    
    
    
    


Home

Last updated: Tue Sep 25 17:17:23 2001
6732 messages in chronological order