Message-ID: <1BEBA5E8600DD4119A50009027AF54A0132E0496@axcs04.cos.agilent.com>
From: pat_thaler@agilent.com
To: Deva_Ranganathan@adaptec.com, eddy_quicksall@ivivity.com,
	pat_thaler@agilent.com
Cc: ips@ece.cmu.edu
Subject: RE: StatSN and overlapped commands
Date: Thu, 7 Aug 2003 18:21:18 -0600 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Deva,

I think Eddy, you and I are all agreeing. A target MAY detect this error. It isn't required to detect. A Reason code for Reject exists that is appropriate for cases where the target detects the error. We should neither prohibit nor require detection.

And yes, Eddy, I did mean 10.17.1.

Pat

-----Original Message-----
From: Ranganathan, Deva [mailto:Deva_Ranganathan@adaptec.com]
Sent: Thursday, August 07, 2003 5:07 PM
To: 'Eddy Quicksall'; pat_thaler@agilent.com
Cc: ips@ece.cmu.edu
Subject: RE: StatSN and overlapped commands


Since it is implementation specific, a target MAY take care of this scenario
by a suitable error response as defined in 
the current spec. If a target implementation can perform this, why prevent
it?  

Thanks

Deva


-----Original Message-----
From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] 
Sent: Thursday, August 07, 2003 4:50 PM
To: pat_thaler@agilent.com
Cc: ips@ece.cmu.edu
Subject: RE: StatSN and overlapped commands


I assume you mean 10.17.1. Yes, the target could give that response but it
should not be required to check the ITT. That is what I meant by "make it an
error". It could take time to do that and the target should not be in the
business of debugging the initiator.

That is what I meant by "make it an error".

I object to the target (or initiator) being required to do anything to cover
cases where the other side screwed up ... unless it could adversely effect
the target (or initiator) such as a crash. 

Eddy

-----Original Message-----
From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] 
Sent: Thursday, August 07, 2003 6:54 PM
To: wrstuden@wasabisystems.com; eddy_quicksall@ivivity.com
Cc: pat_thaler@agilent.com; satran@haifasphere.co.il; julian@cs.haifa.ac.il;
Black_David@emc.com; dcuddihy@attotech.com; ips@ece.cmu.edu
Subject: RE: StatSN and overlapped commands

Eddy,

I'm not sure what you mean by "make it an error". iSCSI already has an error
that covers this situation doesn't it? I'm looking at 10.7.1 on reason code
0x09. Note 2 says this includes invalid TTT/ITT.

Pat

-----Original Message-----
From: wrstuden@wasabisystems.com [mailto:wrstuden@wasabisystems.com]
Sent: Wednesday, August 06, 2003 1:20 PM
To: Eddy Quicksall
Cc: pat_thaler@agilent.com; satran@haifasphere.co.il; julian@cs.haifa.ac.il;
Black_David@emc.com; dcuddihy@attotech.com; ips@ece.cmu.edu
Subject: RE: StatSN and overlapped commands


On Wed, 6 Aug 2003, Eddy Quicksall wrote:

> I don't think we should make it an error if that implies that the 
> target needs to check for the error.

In my most recent note, I'm suggesting we make it an error, but that we let
the target ignore the "error" if it has already terminated the task.

If we don't make it an error, we run into the question of what should a
target do if the first (status-unacknowledged) task needs to support
recovery actions. If the second, same ITT, task is allowed to exist, Data
SNACKs become ambiguous. That strikes me as VERY much against the intent of
data recovery. :-) Just letting the target report this as an error seems the
easiest thing to do.

The reason for letting the target ignore this case is so that we permit
implementations like Pat was describing. If you know you aren't going to do
any recovery (either you aren't supporting it or it's a SCSI write command
and thus the target knows all is done), then it's fine to kill the task, and
then this case isn't ambiguous.

> It seems that if the initiator does this, he probably has a bug or a 
> race condition that will lead to a bug later. So isn't it his 
> responsibility to debug his program?

I agree it's the initiator's problem. The thing is that if we don't make it
an "error", then the target has to deal with the problem, and the corner
cases can get messy.

So to be clear, I'm suggesting the "it's an error you can ignore if it isn't
a problem" approach so that we give different target implementations the
room to deal with the situation as they see fit.

Take care,

Bill