Re: Testing for the execution state (represented by identifying the Initiator Task Tag) MUST precede any other action at the target.
William Studenmund <[email protected]> Fri, 2 Nov 2007 11:31:20 -0700
| Newsgroups | gmane.ietf.ips |
|---|---|
| Message-ID | <[email protected]> |
On Nov 2, 2007, at 10:54 AM, Barry Reinhold wrote: > Question relative to the proper understanding of the following > conformance statement from 3.2.2.1 > > A numbered iSCSI request will not change its allocated CmdSN, > regardless of the number of times and circumstances in which it is > reissued (see Section 6.2.1 Usage of Retry). At the target, CmdSN is > only relevant when the command has not created any state related to > its execution (execution state); afterwards, CmdSN becomes > irrelevant. Testing for the execution state (represented by > identifying the Initiator Task Tag) MUST precede any other action at > the target. If no execution state is found, it is followed by > ordering and delivery. If an execution state is found, it is > followed by delivery. > > Is the proper understanding of this requirement imply that if a task > w/ ITT=100, sent in an iSCSI PDU w/ CmdSN = 10, has been submitted > to the device server and is “executing”, that if another command > with the same ITT and a CmdSN = 12 (no CmdSN 11 has been xmitted) is > received by the target, it should ignore the CmdSN = 12 and submit > the command to the device server? What kind of second packet are you talking about? Your question above is very vague. > So, I could send a Task Management command using the proper ITT > (without the immediate bit set) using an out of order CmdSN and the > device server would process the command, resulting in a response w/ > a status? I believe you are correct. Take care, Bill _______________________________________________ Ips mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ips