RE: StatSN and overlapped commands

[wrstuden@wasabisystems.com]

On Tue, 5 Aug 2003 pat_thaler@agilent.com wrote:

> Julian,
>
> I agree that the initiator is misbehaving, but I don't agree that the
> target should detect that misbehavior. The target SCSI layer thinks the
> command was done when it generated the status. As David said, the target
> keeps the status around so that it can resend it if requested by Status
> SNACK. It doesn't need to keep track of the tag anymore at that point.

Well, I'll add one more opinion to the pot; I agree with Julian. :-) I
agree that the _SCSI_ command is completed, but I think that the iSCSI
task isn't done until the status is ack'd.

Doesn't the target still need to keep track of the tag in case (for a SCSI
read) a data SNACK comes in? It was my understanding that until you get an
ack that the read data all got there, you need to be able to handle a
request for data re-transmit. And to do that, you need the ITT.

As a twisted-but-legal scenario, consider you have a read command (data
from target to initiator) with ITT=5 that completes and the target sends
status. A new read command comes in with ITT=5 but w/o Stat
acknowledgement of the first ITT=5 command. Then a Data SNACK comes in for
ITT=5. Which SCSI command's data should be re-sent?

> If the target had to generate an error when a command came with for a
> tag before the status for a prior command with the same tag was
> acknowledged, then it would have to clear the memory of tags when status
> acks came in which is less efficient than doing it when posting the
> status.

While I agree it's not as efficient, if we don't wait until we get status
ack to clear the ITT, how do we avoid ambiguity in dealing with SNACKs?

Take care,

Bill