Fast multi-task abort model
As promised earlier, this memo describes a possible new iSCSI multi-task
abort model that supports a much more expeditious termination of
affected tasks. I gave it a decent attention, but have not thought
through all the corner cases fully, so please give it a critical read.
If we agree adopting something like this, consider if it should be an
additional behavior when a new key "FastMultiTaskAbort=Yes" is
negotiated by both parties.
So where does the "fast" in FastMultTaskAbort come from?
- Eliminates the CmdSN wait on third-party sessions
- Eliminates the TTT wait on issuing & third-party sessions
- Eliminates the wait on third-party StatSN acks for the issuing
session
And:
- Should work identically for iSCSI-3720 & iSCSI/iSER
- No new SCSI-level requirements (e.g. TAS=1)
However, the downside is that the new model is more complex.
The model description follows.
--
Mallikarjun
Mallikarjun Chadalapaka
Networked Storage Architecture
StorageWorks Division
Hewlett-Packard MS 5668
Roseville CA 95747
cbm [at] rose.hp.com
The following iSCSI protocol actions happen on an initiator iSCSI layer
after issuing a multi-task abort TMF - i.e. one of Abort Task Set, Clear
Task Set, LU Reset, Target Cold Reset, and Target Warm Reset TMFs:
1. The initiator iSCSI layer must not send any more Data-Out PDUs
for affected tasks on the issuing connection of the issuing iSCSI
session once the TMF is sent to the target.
2. Initiator iSCSI layer should receive any responses that the target
may provide for some tasks among the affected tasks (may process them
as usual because they are guaranteed to have chronologically
originated before the TMF response).
3. Initiator iSCSI layer must respond to the Async Message PDU with
AsyncEvent=5 by taking two steps in this order:
a) stop Data-Out transfers on that connection for all active
TTTs for the affected LUN quoted in the Async Message PDU.
b) acknowledge the StatSN of the Async Message PDU via a
Nop-Out PDU with ITT=0xffffffff (i.e. non-ping flavor),
while copying the LUN field from Async Message to Nop-Out.
4. Initiator iSCSI layer receives the task management response
concluding all the tasks in the set of affected tasks.
The following iSCSI protocol actions happen on a target iSCSI layer
receiving a multi-task abort TMF - i.e. one of Abort Task Set, Clear
Task Set, LU Reset, Target Cold Reset, and Target Warm Reset TMFs:
0. Based on the CmdSN ordering, target iSCSI layer waits for all
SCSI Command PDUs of the affected tasks to be received on the
issuing session. On third-party affected sessions, only the
instantiated tasks have to be considered for the purpose of
determining the affected tasks - i.e. no waiting is needed on
third-party sessions. In the case of target-scoped requests (i.e.
target resets), all the commands that are not yet received on
the issuing session in the command stream however can be considered
to have been received with no command waiting period - i.e. the
entire CmdSN space upto the CmdSN of the task management function
can be "plugged".
1. Target iSCSI layer initiates the termination proceedings on all
affected tasks immediately - this may involve interacting with the
local SCSI layer.
2. Target iSCSI layer leaves all active "affected TTTs" (i.e. active
TTTs associated with "affected tasks") valid along with any buffer
allocations for the TTTs intact.
3. Target iSCSI layer generates an Asynchronous Message PDU with a new
AsyncEvent=5 that says "all active tasks for LU with matching LUN
field in the Async Message PDU are being terminated" on:
a) each connection of each third-party session that at least one
affected task is allegiant to, and
b) each connection except the non-issuing connection of the
issuing session that at least one affected task is allegiant
to.
If there are multiple affected LUs (say due to a target reset),
then one Async Message PDU must be sent for each such LU on each
affected connection.
4. Once the local SCSI layer had terminated the SCSI tasks and handed
a TMF Response to it, the target iSCSI layer takes note of last-sent
and unaknowledged StatSN on each of the connections in the iSCSI
session(s) sharing the affected tasks, and waits for acknowledgement
of each such StatSN (may solicit for acknowledgement by way of a
Nop-In). If any new task responses for the affected LU(s) are
meanwhile received from the SCSI layer while waiting for StatSN
acknowledgement(s), those Response PDUs the first SCSI Response
PDU of which is presumably carrying the UA notification - must
be held and queued at the iSCSI layer.
5. For each of the affected sessions, the target iSCSI layer waits
independently for the StatSN acknowledgements.
a) As all StatSNs are acknowledged on the issuing session,
the target iSCSI layer sends the TMF Response in an iSCSI
PDU to the issuing initiator. All task response PDUs held
back at the iSCSI layer in Step#4, if any, are simultaneously
eligible for being placed on the wire as appropriate.
b) As all StatSNs are acknowledged on a third-party session,
all task response PDUs held back at the iSCSI layer in
Step#4, if any, are simultaneously eligible for being placed
on the wire as appropriate.
6. Technically, the task termination is complete in Step#5. Data
transfers corresponding to terminated tasks may however still be in
progress by Step#6. In the case of iSCSI/iSER, these transfers
would be into tagged buffers with STags not owned by any active
tasks. Target iSCSI layer must free up the affected TTTs and the
corresponding buffers as it receives the associated Nop-Out
acknowledgement that the initiator generated in Step#3b (initiator
actions). A target may on an implementation-defined internal timeout
choose to drop the connections that it does not receive the expected
Nop-Out acknowledgement on and reclaim the buffer and TTT resources.
_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
[IETF]
[Linux iSCSI]
[Linux SCSI]
[Linux Resources]
[Yosemite News]
[IETF Announcements]
[IETF Discussion]
[SCSI]
