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.



    John,
    
    I suspect that in most cases these mode page settings would not be done, 
    since most stacks are still SCSI-2 based.
    Hence, any SCSI LLPs that do provide support for these transport specific
    mode pages (ex : FCP-2 implementations) would probably be issuing these 
    mode sense/select's from within the LLP (miniport driver, HBA driver, etc).
    
    The file system and wedge drivers do not muck with these, as you already
    pointed out.
    
    Since these mode pages have transport specific semantics, any SCSI ULP
    (ex : class driver) that attempts to issue mode sense/select for transport
    specific mode pages would first need to interact with some transport
    specific code to determine which transport is being used and what mode
    page format is to be used. Thus, any such class driver would need an
    upgrade to understand the iscsi transport specific mode pages.
    
    Even if there are some management applications that may be trying to set
    these parameters through pass thru mode sense/select commands, they would
    need to now be upgraded to understand iscsi specific versions of these
    transport mode pages. Further, any such management app. would also need to
    develop mechanisms to issue pass-thru text commands or some other
    mechanism if it wished to tweak iscsi parameters.
    
    Hence, I agree with you that there should not be any legacy issue here.
    Any layer or management app that mucks with iscsi parameters will need an
    upgrade anyway and they might as well be upgraded to use a single
    mechanism, login keys.
    
    I think we've beaten this issue to death, and suggest that we call for
    consensus on this issue and move onto other issues.
    
    Regards,
    Santosh
    
    > 
    > 
    > Does anyone know of where a Legacy function would exist, in the Host which
    > would do anything with FirstBurstSize?  I am assuming it would have to be
    > in the SCSI Device Driver, and since we have iSCSI instead, that may not be
    > an issue.
    > I could be wrong but I do not think that it occures in the SCSI Class
    > Drivers.
    > And I do not think it ocures in the File Systems, so where does this Legacy
    > function we are worried about occure?
    > If it is in the SCSI Device Driver it is NOT an 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
    > 
    > 
    > "CONGDON,PAUL (HP-Roseville,ex1)" <paul_congdon@hp.com>@ece.cmu.edu on
    > 09/25/2001 10:14:12 PM
    > 
    > Sent by:  owner-ips@ece.cmu.edu
    > 
    > 
    > To:   "'cbm@rose.hp.com'" <cbm@rose.hp.com>, ips <ips@ece.cmu.edu>
    > cc:
    > Subject:  RE: iscsi : default iscsi mode page settings.
    > 
    > 
    > 
    > 
    > >Julian and Santosh,
    > >
    > >Whether FirstBurstSize should be a text key or not,
    > >IMHO, is (mostly) dependent on the current implementations.
    > >Santosh rightly pointed out several drawbacks of
    > >mandating a new set of mode select/sense operations
    > >that are totally iSCSI-specific since the legacy SCSI
    > >stack (class drivers, services/midlayer) will have no
    > >clue about them.  OTOH, if most of today's SCSI stacks
    > >_do_ perform this mode parameter manipulation in disconnect-
    > >reconnect mode page, that would be a strong argument to
    > >leave FirstBurstSize as a mode page parameter.
    > 
    > Anything iSCSI specific should attempt to follow other iSCSI
    > methods of configuration (e.g. text keys).  We should really
    > be driving towards a single method of parameter negotiation
    > and configuration - especially when the legacy methods
    > have no clue about the new parameters and would require upgrades.
    > 
    > Paul
    > 
    > 
    > 
    > 
    > 
    > 
    
    
    -- 
    #################################
    Santosh Rao
    Software Design Engineer,
    HP, Cupertino.
    email : santoshr@cup.hp.com
    Phone : 408-447-3751
    #################################
    


Home

Last updated: Wed Sep 26 14:17:17 2001
6765 messages in chronological order