iSCSI: abort task & abort task set

["Mallikarjun C." <cbm@rose.hp.com>]

Julian,

iSCSI currently requires two responses to be returned for an aborted task -
one for the original task with a "good" status, and the second for the task
management function (TMF) itself.  So, the following legal behaviors are
required of a target -
    a) plug the CmdSN gap if the command was not received,
    b) send a SCSI response and TMF response if the task still is active,
    c) send a TMF response if the task isn't active (if already complete).

I would like to suggest that we reconsider our approach for case (b) for
 a variety of reasons, to change it to:
    b) send a TMF response signalling that the abort is complete, if the
task
        still is active.

Here are my reasons -

    1. Target iSCSI layer would need to make a SCSI response up on
        an abort of an active task.  It then follows that the iSCSI layer
        may have to make up several SCSI responses on an 'abort task set'.

   2.  The current approach also creates a side effect that isn't readily
        apparent for 'abort task set'.  Initiators would need to stall
processing
        'abort task set' TMF response till task responses (to account for
all
        the tasks in the task set) on multiple TCP connections (possibly on
        different NICs) are received - which I am afraid would tantamount to
        an initiator scoreboard.

    3. The current approach complicates initiator implementations that want
        to process a successful SCSI completion even after they initiated
        timeout processing since on an 'abort task set', initiators can
never
        be sure if the response was pre-abort, or post-abort (made up "good"
        status).  I believe it is worth preserving this implementation
choice.

   4.  I am further concerned that iSCSI is possibly in violation of the
spirit of
        SAM-2, rev20.
         - clause 5.6.2 that states -
"When an initiator causes its own task(s) to be aborted, no notification
that the task(s) have been aborted shall be
returned to the initiator other than the completion response for the command
or task management function action
that caused the task(s) to be aborted and notification(s) associated with
related effects of the action (e.g., a target
reset unit attention condition)."

         - clause 5.3.1 that states -
"GOOD. This status indicates that the device server has successfully
completed the task."

I propose that the target deliver only the TMF response on an abort of
an active task on an 'abort task' TMF, and not transmit an 'abort task set'
TMF response until all the current StatSN's on all connections (as on the
completion of "abort task set') in the session are ack'ed.  This ack may be
solicited by way of a NOP-IN with valid TTT.

This gives the determinism to initiators that  (a) abort task set TMF
response
signifies that the entire task set had been dealt with, and (b) every task
response
is a true SCSI end-to-end reponse (not generated by iSCSI), besides doing
away with SCSI-response code in the target iSCSI layer.

Comments?  Did I miss any corner cases?

Regards.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668
Roseville CA 95747