RE: StatSN and overlapped commands

[wrstuden@wasabisystems.com]

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