[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: StatSN and overlapped commands

    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).
    -----Original Message-----
    From: Eddy Quicksall [] 
    Sent: Wednesday, August 06, 2003 3:23 PM
    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?
    -----Original Message-----
    From: [] 
    Sent: Wednesday, August 06, 2003 3:12 PM
    Subject: RE: StatSN and overlapped commands
    On Wed, 6 Aug 2003 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.
    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,


Last updated: Thu Aug 07 16:19:22 2003
12789 messages in chronological order