Date: Tue, 5 Aug 2003 18:45:40 -0700 (PDT)
From: wrstuden@wasabisystems.com
To: pat_thaler@agilent.com
Cc: 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: <1BEBA5E8600DD4119A50009027AF54A0132E0486@axcs04.cos.agilent.com>
Message-ID: <Pine.NEB.4.53.0308051820430.532@neverwinter.home-net.icnt.net>
References: <1BEBA5E8600DD4119A50009027AF54A0132E0486@axcs04.cos.agilent.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

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