Message-ID: <AEC4671C8179D61194DE0002B328BDD2858008@atlops.ivivity.com>
From: Eddy Quicksall <eddy_quicksall@ivivity.com>
To: wrstuden@wasabisystems.com, pat_thaler@agilent.com
Cc: 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
Date: Wed, 6 Aug 2003 15:33:15 -0400 
MIME-Version: 1.0
Content-Type: text/plain
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

I realize I may have not been clear ... here is what I'm trying to say:

The original example was that the initiator sent another command but did not
acknowledge that it got the status (and the commands were untagged). That
progressed into it using the same ITT.

Since the reuse of the ITT argument only applies if he did not acknowledge
he got the status then I see these both as the same problem; and that is
that the initiator is most likely overlapping commands (even though this
particular overlap can't be caught at the SCSI layer).

Eddy

-----Original Message-----
From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] 
Sent: Wednesday, August 06, 2003 3:23 PM
To: wrstuden@wasabisystems.com; pat_thaler@agilent.com
Cc: 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

I don't think we should make it an error if that implies that the target
needs to check for the error.

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?

Eddy

-----Original Message-----
From: wrstuden@wasabisystems.com [mailto:wrstuden@wasabisystems.com] 
Sent: Wednesday, August 06, 2003 3:12 PM
To: pat_thaler@agilent.com
Cc: 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 pat_thaler@agilent.com wrote:

> Julian,
>
> For recovery, the target has to remember the status, but that doesn't
> mean it has to keep the task information around. It would have the
> status message linked to StatSN but it would be typical to clear away
> any task context when that message is generated. Remember that when
> things are very busy it might get a single acknowledgement that
> acknowledges multiple status messages from multiple tasks. It isn't
> efficient to have to go back to do the task context clean up when the
> status ack comes.
>
> It is the initiator's job to not shoot itself in the foot by issuing a
> new command with the same task tag as one that it hasn't gotten status
> on yet. For the target, once the status is generated, the task is gone.
> The status message may still be there available for a resend, but the
> task is gone. I don't see any requirement in iSCSI or SCSI to do
> anything other than that.

Pat,

Would this be agreable: we make it an error for the initiator to re-use a
task tag for which it hasn't received status, and we let the target
terminate the iSCSI task after sending the status if it is not going to do
any recovery. Likewise, we permit the target to choose to not terminate
the iSCSI task until it receives status.

That way you're fine if you shut the task down after sending status, but
likewise targets that _don't_ shut the task down until receiving status
are perfectly ok to complain if they notice the task re-use. And I'd
expect regression testing targets to keep the task around until status ack
to catch this error case.

While I agree the spec is unclear, I read it and took away the idea that
the ITT can't be re-used until status is ack'd. :-)

Please note I'm talking about the iSCSI task in all of the above. I agree
with David that the SCSI task is over before/when we send status. ;-)

Take care,

Bill