RE: iSCSI: login issue - partial consensus call

["John Hufferd" <hufferd@us.ibm.com>]

I would hand these out one after the other first Miniport gets ISID of 1,
next 2, etc.

Now I know you could have said the above, so I probably I did not interpret
your statement correctly.

.
.
.
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


"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