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

    RE: StatSN and overlapped commands

    On Tue, 5 Aug 2003 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,


Last updated: Wed Aug 06 00:19:22 2003
12776 messages in chronological order