Date: Wed, 6 Aug 2003 13:20:25 -0700 (PDT)
From: wrstuden@wasabisystems.com
To: Eddy Quicksall <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
In-Reply-To: <AEC4671C8179D61194DE0002B328BDD2858006@atlops.ivivity.com>
Message-ID: <Pine.NEB.4.53.0308061308420.166@neverwinter.home-net.icnt.net>
References: <AEC4671C8179D61194DE0002B328BDD2858006@atlops.ivivity.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

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