SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: iSCSI: abort task & abort task set




    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>
    Sent by: owner-ips@ece.cmu.edu

    12/03/2001 01:33 AM

           
            To:        "ips" <ips@ece.cmu.edu>
            cc:        
            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





Home

Last updated: Mon Dec 03 22:17:47 2001
7986 messages in chronological order