Re: iSCSI: login issue - partial consensus call

[Santosh Rao <santoshr@cup.hp.com>]

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




"Martin, Nick" wrote:

> 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:santoshr@cup.hp.com]
> Sent: Thursday, September 06, 2001 1:57 PM
> To: ips@ece.cmu.edu
> 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
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