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