Subject: RE: iSCSI: login issue - partial consensus call

From: "Martin, Nick" <[email-masked]>
Date: Thu, 6 Sep 2001 15:33:14 -0500

Santosh,

If an iSCSI HBA driver is going to live within the SCSI subsystems in
today's operating systems, it will be told almost nothing about the host
through those interfaces.  When the driver initializes, it is likely to
be told only the PCI addresses of its adapter(s).  It is provided
interfaces only to expose its SCSI request, ioctl request, and hardware
interrupt service routines.  It will not get the host name, or an IP
address via interfaces in the SCSI subsystem.  Interfaces to collect
information such as IP address, and host name which are available to
network drivers, are not available to many storage drivers.  These and
anything else needed will have to be collected from other interfaces.
Some OS environments will provide a way for the SCSI driver to initiate
queries for this information, some will allow static pre-configuration,
others will need to wait for something to poke the information in
through custom ioctl interfaces, or retrieve or construct what is needed
from non-volatile storage on the HBA card.  

This is partly a chicken and egg problem.  The host name for example is
normally retrieved from the system disk which can not be read until the
storage driver has completed its initialization.  If the boot storage
controller could ask the OS for the host name, it would not get a good
answer.

Operating systems will eventually comprehend the need for driver APIs
for iSCSI which blend network and storage requirements, but initial
implementations will be entirely supplied by the HBA or driver vendor.

IMHO, if a driver can initialize (bootstrap) without information from
other sources, you make life much easier for the driver writers,
testers, and users.  If all iSCSI drivers operating within the same host
need to agree on something which is not available through a pre-existing
interface, there will be problems.  If the administrator has to manually
set the same InitiatorName (and/or AccessID) for each iSCSI driver, that
is one thing.  If he has to manually set non-overlapping ranges of ISIDs
for each driver instance that will be more error prone.

The suggestion by Michael Schoberg to eliminate initiator assigned ISID,
and only use TSID which is already guaranteed to be unique makes sense
to me.  

As Michael noted, we are a bit off of the consensus topic.

Thanks,
Nick
-----Original Message-----
From: Santosh Rao [mailto:[email-masked]]
Sent: Thursday, September 06, 2001 1:57 PM
To: [email-masked]
Subject: Re: iSCSI: login issue - partial consensus call

"Martin, Nick" wrote:

> The problem is that iSCSI does not and will not specify how two HBAs
> from different vendors installed in the same Initiator should or could
> get a range of ISIDs for their exclusive use.  This will be operating
> system specific and vendor defined.  It is uncertain that the same
tool
> or repository would be used by all HBA vendors in any environment.
> Given this, accidental overlap in ISID space is not unlikely.

In the above scenario, if the HBAs do not have an interface to receive a
range of ISIDs from the OS iscsi driver, then, they must also lack an
interface to be handed down an iscsi initiator node name from the
OS driver. Without using a common iscsi initiator node name, the ISID
issue
does not arise for multiple HBAs. [since each would be using its own
iscsi
name].

OTOH, if the HBAs have an interface to be handed down an iscsi initiator
node name from the OS driver, there's no reason for them to not provide
an
interface to be handed down an ISID or a range of ISIDs for their use.

I am in favor of option (A) since it is the simplest and a well designed
HBA should be providing interfaces for the OS driver to assign the HBA
an
iscsi initiator node name as well as a range of ISIDs, thus, rendering
Nick's scenario unlikely.

>
> Given that there is no one way to play right, we must make sure that
> everyone can at least play nice.
>
> My expectation is that sessions are infrequently established and long
> lived.  ISIDs may be re-used at will by their current owners.  When no
> "already owned" ISIDs are available, or an attempt to re-use an
"already
> owned" ISID failed, and HBA would need to a) "probe" for a new
available
> ISID or b) fail the request to establish the session.  Session
recovery
> should not be attempted unless a session is known to have failed.
>
> If tools are available, and the administrator has used them correctly,
> then HBAs will not collide in ISID space.  If the tools are not
> available or were not used correctly, I would hope the second HBA can
> still attempt to come up without impacting the sessions established by
> the first.

If the tools were not available, how does the 2nd HBA get assigned the
same
iscsi initiator node name as the first ? The ISID issue is only
applicable
if both HBAs are sharing the same iscsi initiator node name.

I would like to understand the rationale behind an HBA interface
allowing
an initiator node name to be assigned, but not an ISID or a range of
ISIDs
(?).

Regards,
Santosh

---

From: Sandeep Joshi <[email-masked]>
Date: Thu, 06 Sep 2001 19:15:18 -0400

If we can step back a bit on this consensus call, I do
agree with Nick on Mike's suggestion.  

http://www.pdl.cmu.edu/mailinglists/ips/mail/msg06373.html

-Sandeep

---

From: Santosh Rao <[email-masked]>
Date: Thu, 06 Sep 2001 18:26:41 -0700

Nick,

I understand the issues you point out below, since we are dealing with the
very same issues, as an OS vendor.
However, the iscsi architecture by allowing multi-connection sessions that
can span multiple HBAs, requires an OS component to be present that is
iscsi aware [an iscsi OS driver].

All iscsi'ness cannot be hidden on HBA firmware if one wishes to support
multi-connection sessions. The CmdSN, Initiator Task Tag, ExpStatSN need to
be assigned by an OS driver that is co-ordinating across multiple HBAs. The
OS driver should also be capable of assigning ISIDs to the HBA while
establishing a session.

Why is it an issue for the OS driver to be assigning ISID while issuing an
"Estabish Session" mailbox command or while adding a connection to an
existing session ?

Regarding the issue of co-ordinating ISIDs & multi-connection sessions
across multiple HBA types, this is only possible if a mid-layer component
is present in the OS, co-ordinating across the vendors' drivers. In its
absence, multi-connection sessions are only possible within the HBAs of a
given vendor type, and each vendor type uses a different iscsi name.

Regards,
Santosh

---

From: "Eddy Quicksall" <[email-masked]>
Date: Fri, 7 Sep 2001 11:38:47 -0400

Isn't the topic how to reset a session? If so, I think this is still within
the topic.

I had put in a suggestion that we use the TSID but I have not seen a
response yet. This is consistent with what you are saying below.

Can we work on that for a bit and see if that solves at least the reset
dilemma?

Eddy

-----Original Message-----
From: Martin, Nick [mailto:[email-masked]]
Sent: Thursday, September 06, 2001 4:33 PM
To: [email-masked]
Subject: RE: iSCSI: login issue - partial consensus call

Santosh,

Thanks,
Nick
-----Original Message-----
From: Santosh Rao [mailto:[email-masked]]
Sent: Thursday, September 06, 2001 1:57 PM
To: [email-masked]
Subject: Re: iSCSI: login issue - partial consensus call

tool

"already
available
recovery

Regards,
Santosh