Re: iSCSI: abort task & abort task set

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

Resolution of this certainly requires an offline discussion -
which we two plan to have.  But one comment to make my proposal
clear to the list.

> 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.
> 
> +++ that may result in an initiator reusing prematurely an ITT and
> being hit by a late arriving status
> for a "former" task - i.e. non-deterministic behavior +++

That is not possible since as I said above, the 'abort task set'
TMF response is sent only after all StatSN "snapshots" are ack'ed 
on all connections.
--
Mallikarjun

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


Julian Satran wrote:
> 
> Mallikarjun,
> 
> Comments in text - Julo
> 
> PS - I would like also to point out that we may want to consider a
> very simple alternative to the barrier scheme outlined in 9.4
> - that will require less cooperation between initiator and will be
> simpler to read and implement.
> I will outline such a scheme soon.
> 
>   "Mallikarjun C."
>   <cbm@rose.hp.com>                       To:        "ips"
>   Sent by: owner-ips@ece.cmu.edu  <ips@ece.cmu.edu>
>                                           cc:
>   12/03/2001 01:33 AM                     Subject:        iSCSI:
>                                   abort task & abort task set
> 
> 
> 
> 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.
> +++ That is not entirely correct. The whole purpose of requiring the
> target to send a "good status" is to allow the initiator to send the
> response immediately and have the initiator mark its internal data
> structures as aborted - but avoid reusing ITT untill it gets the good
> answer.
> This way initiator can make progress and it can be sure that it won't
> be surprised by an "old" answer after it has reused the ITT
> +++
>    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.
> +++ see above +++
>   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)."
> +++ I did say explicitly that the good status is a "good-will" message
> between iSCSI target and initiator. It does not have to reach SCSI.
> SAM also allows statuses that have been sent before an abort was
> executed but received after the TM response to be delivered or not at
> initiators will +++
>         - 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.
> 
> +++ that may result in an initiator reusing prematurely an ITT and
> being hit by a late arriving status
> for a "former" task - i.e. non-deterministic behavior +++
> 
> 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?
> 
> +++ see above +++
> 
> Regards.
> --
> Mallikarjun
> 
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> Hewlett-Packard MS 5668
> Roseville CA 95747