RE: Re: Last Call Response Fence resolution

In the text below, there is one thing I am not sure
I understand correctly.  The text in 3.3.1, item 1 (and
implicitly item 2) says that "MUST be chronologically
delivered after all the preceding responses... to the
application client on the initiator.

Similarly in 3.3.2 item b) says "target iSCSI layer 
takes note of last-sent and unacknowledged StatSN 
on each of the connections in the iSCSI session, and 
waits for acknowledgement (SHOULD solicit for 
acknowledgement by way of a Nop-In) of each such 
StatSN to clear the fence."

Implicit in 3.3.2 is knowledge of the timing of delivery
to the iSCSI layer, not necessarily to the "application
client".  I do not believe there is any defined time marker
or pollable status available to a target that indicates when 
delivery to the "application client" actually occurs that
could be used to satisfy 3.3.1.  This is the
generic ordering question at the root of my continued
concern about this approach.

Since software constituting the application client (including
kernel, OS, file system, application, etc.) must be designed
to be tolerant of this ambiguity in any case, I believe we
are spending a lot of effort creating an ordered case where
the rare cases of misordering are already managed behavior.

Bob

-----  original text offered by Mallikarjun  -----------------
 
3.3.1 Model Description
Target SCSI protocol layer hands off the SCSI response messages to the
target iSCSI layer by invoking the "Send Command Complete" protocol data
service ([SAM2], clause 5.4.2) and "Task Management Function Executed"
([SAM2], clause 6.9) service.   On receiving the SCSI response message,
iSCSI layer exhibits the Response Fence behavior for certain SCSI
response messages (section 3.3.3 describes the specific instances where
the semantics must be realized).  Whenever the Response Fence behavior
is required for a SCSI response message, the target iSCSI layer MUST
ensure that the following conditions are met in delivering the response
message to the initiator iSCSI layer:
(1) Response with Response Fence MUST chronologically be delivered after
all the "preceding" responses on the I_T_L nexus, if the preceding
responses are delivered at all, to the application client on the
initiator. 
(2) Response with Response Fence MUST chronologically be delivered prior
to all the "following" responses on the I_T_L nexus. 
The "preceding" and "following" notions refer to the order of hand-off
of a response message from the target SCSI protocol layer to the target
iSCSI layer.

3.3.2 iSCSI Semantics with the Interface Model
Whenever the TaskReporting key (section 9.1) is negotiated to
ResponseFence or FastAbort for an iSCSI session and the Response Fence
behavior is required for a SCSI response message, the target iSCSI layer
MUST perform the actions described in this section for that session.:
a) If it is a single-connection session, no special processing is
required.  Standard SCSI Response PDU build and dispatch process
happens. 
b) If it is a multi-connection session, target iSCSI layer takes note of
last-sent and unacknowledged StatSN on each of the connections in the
iSCSI session, and waits for acknowledgement (SHOULD solicit for
acknowledgement by way of a Nop-In) of each such StatSN to clear the
fence.  SCSI response with the Response Fence flag must be sent to the
initiator only after receiving acknowledgements for each of the
unacknowledged StatSNs.
c) Target iSCSI layer must wait for an acknowledgement of the SCSI
Response PDU that carried the response which the target SCSI layer
marked with the Response Fence flag.  The fence must be considered
cleared after receiving the acknowledgement.
d) All further status processing for the LU is resumed only after
clearing the fence.  If any new responses for the I_T_L nexus are
received from the SCSI layer before the fence is cleared, those Response
PDUs must be held and queued at the iSCSI layer until the fence is
cleared.

_______________________________________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips