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.



    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. (??). ]
    
    begin:vcard 
    n:Rao;Santosh 
    tel;work:408-447-3751
    x-mozilla-html:FALSE
    org:Hewlett Packard, Cupertino.;SISL
    adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
    version:2.1
    email;internet:santoshr@cup.hp.com
    title:Software Design Engineer
    x-mozilla-cpt:;21088
    fn:Santosh Rao
    end:vcard
    


Home

Last updated: Tue Sep 25 18:17:19 2001
6734 messages in chronological order