SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: login issue - partial consensus call



    Jim,
    
    Sounds like a good suggestion. Can we start another thread to get a
    consensus on this?
    
    If we do this, we need to document it so Miniport writers all know the
    procedure.
    
    Eddy
    
    -----Original Message-----
    From: Jim Hafner [mailto:hafner@almaden.ibm.com]
    Sent: Friday, September 07, 2001 12:23 PM
    To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu
    Subject: RE: iSCSI: login issue - partial consensus call
    
    
    
    Eddy,
    
    I have ideas on how this ought to be done, analogous to way that
    InitiatorName would get assigned.
    
    Take WinXX for example,  I'd have a well-defined registry key where the
    miniports would look for their InitiatorName. The install of the first
    iSCSI miniport driver would look for that key, not find it and then
    instantiate whatever name is provided by the software installer.  After
    that, any other driver installation (hopefully all driver installers would
    use the same key) would see that value and accept it.  If not, then they
    could use another vendor-key which would render them as being a 'separate
    iSCSI Node' (and the conflict issues go away).
    
    In a similar way, the registry could hold ranges of ISIDs for each driver
    that installed.  A driver on installation would claim some range of ISID's
    not already claimed by other drivers.  If a driver claimed too many, then
    the next install might fail or trigger a management interface to reassign.
    If a driver didn't play by these rules (either because it didn't want to or
    was broken) then the customer probably get a new vendor!
    
    Right now, miniport drivers already get some (typically vendor-specific)
    information from the registry.  There is no reason to believe WE can't
    cooperate in determining well-known keys for this purpose.
    
    I suggested in a private e-mail with David Black that we could make this
    ISID partitioning assignment a bit easier. For example, if we simply had in
    the registry a 'counter' for each miniport as it loaded.  This counter
    could map nicely to a Portal Group Tag.  Then we embed the portal group tag
    in the ISID (in some field within the ISID).  Then you get explicit
    partitioning of ISIDs without a direct management interface that can screw
    up (David's concern).  The drivers effectively enumerate themselves (and
    perhaps multiple portal groups for each driver, as needed) and the rest is
    for free.  I think that drivers already enumerate themselves anyway, so
    this shouldn't be a problem.
    
    Similar things could happen for Unix and friends by just having a defined
    /etc/initiatorname file and enumeration of the drivers in /dev/iscsi.
    
    I didn't think this was such a big deal!
    
    Jim Hafner
    
    
    "Eddy Quicksall" <eddy_quicksall@ivivity.com>@ece.cmu.edu on 09/07/2001
    06:51:06 am
    
    Please respond to <eddy_quicksall@ivivity.com>
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   John Hufferd/San Jose/IBM@IBMUS, "Sandeep Joshi"
          <sandeepj@research.bell-labs.com>
    cc:   <ips@ece.cmu.edu>
    Subject:  RE: iSCSI: login issue - partial consensus call
    
    
    
    John,
    
    We really should do this so a driver can be written for existing OS's. How
    would you hand out ISIDs when a Miniport is being loaded?
    
    Eddy
    
    -----Original Message-----
    From: John Hufferd [mailto:hufferd@us.ibm.com]
    Sent: Thursday, September 06, 2001 3:21 PM
    To: Sandeep Joshi
    Cc: ips@ece.cmu.edu
    Subject: Re: iSCSI: login issue - partial consensus call
    
    
    
    I understand you point, however, the discussion we had on this, talked
    about each HBA needing to have an install process that is OS specific.  It
    was suppose to be an OS specific install or startup process that handed out
    the ISIDs (or ISID ranges).
    
    I think your point is that you wish that there was no reason to interact
    with the OS, in order to get installed.  I do not think that is a good
    assumption.
    
    It is the OS that needs to let the HBA know what the iSCSI Initiator Node
    Name is, so that the HBA can configure to use it.  It might as well hand
    out the ISIDs at the same time.
    
    You are suggesting that making the ID of the iSCSI HBA only a HW item.
    This is not where we came down previously.  You want to make your job of
    interfacing with the OS, simpler, and put more burden on the administrator.
    This was the mistake we made with FC and I would not like to see that
    repeated here.  You say that there needs to be Jumpers or switches, well
    this is up to your adapter.  We use to do that kind of stuff before the
    Plug and Play started working with the OS.  We need to work with the OS in
    a similar manor.
    
    .
    .
    .
    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
    
    
    Sandeep Joshi <sandeepj@research.bell-labs.com>@research.bell-labs.com on
    09/06/2001 11:44:00 AM
    
    Sent by:  sandeepj@research.bell-labs.com
    
    
    To:   John Hufferd/San Jose/IBM@IBMUS
    cc:   ips@ece.cmu.edu
    Subject:  Re: iSCSI: login issue - partial consensus call
    
    
    
    
    John,
    
    Is this what you are referring to ? (Sec 1.3 of Naming & Discovery)
    
    > b) The ISID name space of the iSCSI Initiator should be partitioned
    >       among the intiator portal groups.
    
    How do you perceive this will be achieved in practice ?
    
    This can turn out to be an nightmare for HBA vendors.
    IRQ settings, jumpers, or setup programs which run at boot
    instantly come to mind.
    
    Ideally, ISIDs should work as SCAM works but that would involve
    adding a mid-layer to OSes, to distribute that ISID name space.
    Modifying OSes in the field is tough, as we all know.
    
    I realize the standard wont mandate such configuration items
    but I'd rather we not add rules which would force such
    configuration tweaks to become necessary.
    
    We should reconsider the above rule and its consequence on
    the login issue Nick brought up.
    
    Regards,
    -Sandeep
    
    John Hufferd wrote:
    >
    > By the way, the OS is also suppose to have a way to hand out (partition
    up)
    > ISIDs to the various iSCSI Initiator functions, whether they are Software
    > or Hardware.
    >
    > So, even though,  I was initially swayed by Nick's Arguments -- we
    require
    > the OS to partition up the ISID space and hand out specific ISIDs or
    ranges
    > of ISIDs (in some manor) to the iSCSI Initiator functions (regardless of
    > whether they are in Software or Hardware) -- I do not now see, if the
    > implementation is as specified in our spec., how there is a conflict in
    > ISID.
    > .
    > .
    > .
    > 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
    
    
    
    
    
    
    


Home

Last updated: Fri Sep 07 14:17:16 2001
6433 messages in chronological order