|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: StatSN and overlapped commandsI 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
Home Last updated: Thu Aug 07 16:19:22 2003 12789 messages in chronological order |