Message-ID: <AEC4671C8179D61194DE0002B328BDD26A7D2D@ATLOPS>
From: Eddy Quicksall <eddy_quicksall@ivivity.com>
To: wrstuden@wasabisystems.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: clearing SCSI objects
Date: Mon, 5 May 2003 18:57:19 -0400 
MIME-Version: 1.0
Content-Type: text/plain
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

If you don't worry about it, you will either have to:

1) have lots of initiator structures available
2) not support multiple Initiator Ports
3) not be fully SCSI compliant

The Microsoft Initiator will use a different ISID each time it logs on. It
will log on with each boot and there is no guarantee that it will use the
same ISID set with each boot. I think multiple applications will also be
able to login at the same time ... each with a different ISID. If they login
and logout with execution, you may run our of structures

Eddy


-----Original Message-----
From: wrstuden@wasabisystems.com [mailto:wrstuden@wasabisystems.com] 
Sent: Monday, May 05, 2003 6:50 PM
To: Eddy Quicksall
Cc: David Black (Black_David@emc.com); ips@ece.cmu.edu
Subject: RE: iSCSI: clearing SCSI objects

On Sun, 4 May 2003, Eddy Quicksall wrote:

> David,
>
> I'm wondering what other targets are doing about this. Was it thought
about
> during the design phase?

Our (Wasabi's) target isn't going to do this, unless there is a strong
indication that it's needed/required for certification. I see no real
reason to do this as it's not conveying any value.

> I'm thinking I will keep an LRU list and if I run out of structures to
> handle SCSI Initiator Ports (and there are no persistent reserves
> outstanding), I'll just discard the oldest structure. That will give a
power
> on reset UA if that InitiatorName+ISID is used again.
>
> Does that seem like a logical solution?

I think it's far simpler to not worry about it, or be clearer about when
we worry about it. SAM was written with parallel and FC SCSI in mind.
While there are obvious references to iSCSI, we are only now gaining
experience about what needs tweaking in light of iSCSI.

I'd say start with asking why SAM says the target needs to set a UA, and
see if that applies here. It's my understanding that parallel SCSI has no
way for the target to asynchronously just tell the initiator something.
Likewise, the initiator has no way to directly notice the loss of an I_T
nexus.

iSCSI, though, doesn't have those limitations. For instance, we can send
Asynchronous messages with SCSI sense data. We also have one or more TCP
connections, and rules for adding connections to a session. The up-shot is
that the initiator will realize if it looses the I_T nexus due to
transport issues. For instance, when it goes to add a connection to a
session, it will be told that no such session exists (top of page 60 in
draft 20) -> the session (I_T nexus) is dead. Alternately if the initiator
chooses to do session reinstatement, it knows it is loosing the old I_T
nexus (that's what it's telling the target to do, after all :-) .

So I'd think that the best thing to do here is push back on SAM for iSCSI,
and ignore the need to assert the UA for I_T nexus loss in the cases where
the initiator will notice it itself.

Note I'm hedging my words, since I think we still need a UA for nexus loss
if it happens in a way the initiator won't notice.

Thoughts?

Take care,

Bill