|
The problem is that the definition of "previous" in this
context is most likely flawed.
The "Response Fence" is merely an internal and
untestable state machine input that
attempts to order the transmission of responses in the
target port's queue.
It does
nothing to improve the overall ordering of the responses at the
application
client.
Drivers for generic SCSI transports must always be aware
that requested operations
report completion with a more or less arbitrary time
relationship to each other and must be
designed to tolerate that.
Using LOGICAL UNIT RESET as an example, the operation does
not act only on
the device server. As it passes down through the
initiator stack, it may clean out
previously offered commands that have not yet been
transported. Then as it
passes up through the target stack, it may clean out
previously offered commands
that have not yet been operated on. As it passes
through the device server
execution path, it may clean out previously offered
commands that have begun
execution and some that have completed execution
without yet responding. As its
response passes back down the target stack, it may clean up
commands
that have completed for which the response has not yet been
transmitted, and as
it passes back up the initiator stack, it may clean up
commands for which the
response has been transmitted, but not yet been made
available to the driver or
application. SAM-4 attempts to define the passage
through the target port,
through the device server, and back to the target
port. However, beyond the
initiator port is outside the SAM-4 scope, and even
where it is defined,
the "shall ensure"s are unlikely to be testable and in
some cases not implementable.
Will I sometimes get command complete indications for
commands after
a LOGICAL UNIT RESET response is received? You bet. Response
Fence doesn't
change that.
Will I sometimes get command
aborted indications for commands after
a
LOGICAL UNIT RESET is response is received? You
bet. Response Fence
doesn't change that.
Is this a problem? It never has been in the
past, why is it now?
Can you test the corner conditions for a fence
operation? I doubt it. The
existence of the "Response Fence" argument is internal to
the target
implementation and invisible to
testing.
Bob
From: Elliott, Robert (Server Storage) [mailto:Elliott at hp.com] Sent: Wednesday, January 03, 2007 3:35 PM To: ips at ietf.org Subject: RE: [Ips] Response Fence Flag SAM-3 and SAM-4 require all transport protocols to tag the TMF responses with the requests: "Each SCSI transport protocol shall allow a Received Task Management Function Executed confirming completion of the requested task to be associated with the corresponding Send Task Management Request." Although iSCSI was based on SAM-2, it complies with that rule. The Fence concept is asking for more than that - it wants the target to be able to ensure that all previous commands/TMFs are complete before delivering a particular TMF response (e.g., for a LOGICAL UNIT RESET). Since iSCSI doesn't have ACKs, the target must wait for the next PDU from the initiator with an updated ExpStatSN. 06-341r0 discussed an alternative - add a Delivery Result output to the Send Command Complete and Task Management Function Executed confirmations (as previously proposed in 04-072r0 for a different purpose). This would let the device server/task manager wait for all the previous commands/TMF responses to complete (be ACKed) before proceeding to make additional calls (e.g., Task Management Function Executed for a LOGICAL UNIT RESET). However, iSCSI allows the target port to send a NOP-IN to force delivery of a NOP-OUT with ExpStatSN, rather than passively wait for a PDU to show up. The device server/task manager must instruct the target port when to do this, and the Request Fence argument serves that purpose. Target ports using protocols without such a force mechanism are still OK - they will just wait for protocol-specific delivery confirmations (e.g. ACKs). --
|
_______________________________________________ Ips mailing list Ips at ietf.org https://www1.ietf.org/mailman/listinfo/ips