Re: iSCSI:SCSI responses for iSCSI errors

["Julian Satran" <Julian_Satran@il.ibm.com>]

Ken,

It is entirely up to the implementer.
IMHO R2Ts that where not sent yet don't have to be sent.
A response PDU will close nicely the cycle.
The whole purpose of the delay is to avoid having PDUs carrying the ITT 
hit the target
when the target has cleared its own control structures referring to the 
task.

Julo





"Ken Sandars" <ksandars@eurologic.com>
Sent by: owner-ips@ece.cmu.edu
31-10-01 19:08
Please respond to "Ken Sandars"

 
        To:     <ips@ece.cmu.edu>
        cc: 
        Subject:        iSCSI:SCSI responses for iSCSI errors

 

Gidday all,

With reference to 3.4.2, when a target detects an error
does:

'...MUST wait until it receives a Data PDU with the F
bit set, in the last expected sequence, before sending the 
Response PDU' 

imply the target waits for the entire Expected Data Transfer
Length worth to be transferred? 

If so, the target may have to R2T for the solicited data! Should
it R2T with 'correct' values, regardless of what the initiator sent?

In this case it is possible that this clean-up action actually solicits
all the required data, however, the command is still going to get
a response with sense data indicating an abort.

Is it possible to just reject the original command PDU when validity 
checking picks up one of these errors? Any Data-Out PDUs
in the pipeline which belong to this rejected command can be silently
discarded by the target. What am I missing?


Thoughts?

Ken Sandars
ksandars@eurologic.com
Eurologic Systems
+44 117 930 9616