[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Google
  Web www.spinics.net

Re: Testing for the execution state (represented by identifying the Initiator Task Tag) MUST precede any other action at the target.



On Nov 2, 2007, at 11:31 AM, William Studenmund wrote:

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.

Having re-read the TMReq documentation, I take the above back. :-)

The TMReq for an abort will have its own ITT, different from that of the task it is aborting. So using the ITT of the command you want to abort is flat-out wrong.

My understanding of the text way above regarding CmdSN is that it really matters for linked commands. So for a Linked command, a subsequent command request doesn't have to wait for CmdSN processing before it gets handed down to the existing task.

Take care,

Bill
_______________________________________________
Ips mailing list
Ips@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ips

[IETF]     [Linux iSCSI]     [Linux SCSI]     [Linux Resources]     [Yosemite News]     [IETF Announcements]     [IETF Discussion]     [SCSI]

Add to Google Powered by Linux