Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET

From: "Eddy Quicksall" <[email-masked]>
Date: Thu, 2 Jun 2005 10:29:02 -0400

>       LOGICAL UNIT RESET: All outstanding tasks from all initiators for
>                       the LU identified by the LUN field in the LOGICAL
>                       UNIT RESET task management function.

Regarding "all initiators" above. In the context of 10.6.2(b), how would 
"The initiator" know anything about "all initiators"?

Eddy

----- Original Message ----- 
From: "Mallikarjun C." <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, May 31, 2005 7:23 PM
Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET

> Responding to my own comment (since I seem to have done such a fine job of 
> "aborting" this email thread).....
>
>> I think it'd be a good idea to elaborate on LU Reset, and the two
>> flavors of Target Reset in a formal IETF doc.
>
> I am concerned that the current lack of detailed specification would
> allow targets that might even cause silent data corruptions to qualify as 
> RFC 3720-compliant.
>
> Here are what I believe to be semantics applicable to all TMF requests
> that can potentially terminate multiple tasks.  I do not know the IETF 
> process well enough here, but I suggest that we consider this text 
> replacing the existing section 10.6.2 in RFC 3720 - so the new text can 
> cover all the TMFs that can impact multiple tasks.  This is basically a 
> superset of the current 10.6.2 semantics.
>
> Comments are welcome.
>
> Mallikarjun
>
> -----------------------------------------------------------------------
>
>
> 10.6.2.  Task Management Actions on Requests Affecting Multiple Tasks
>
> The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, 
> TARGET WARM RESET, and TARGET COLD RESET Task Management function requests 
> consists of the following sequence of actions in the
> specified order on each of the entities.
>
> The initiator:
> a) Issues ABORT TASK SET/CLEAR TASK SET/LOGICAL UNIT RESET/TARGET
>    WARM RESET/TARGET COLD RESET request.
> b) Continues to respond to each target transfer tag received
>    for the "affected" (*) tasks.
> c) Receives any responses that the target may provide for some
>    tasks among the affected tasks (may process them as usual
>    because they are guaranteed to be valid).
> d) Receives the task management response, thus concluding
>    all the tasks in the set of affected tasks.
>
>
> The Target:
>
> a) Receives the ABORT TASK SET/CLEAR TASK SET/LOGICAL UNIT
>    RESET/TARGET WARM RESET/TARGET COLD RESET request.
> b) Waits for all currently valid target transfer tags of the
>    affected tasks to be responded.
> c) Based on the CmdSN ordering, waits (concurrent with the
>    wait in step (b)) for all commands of the affected tasks
>    to be received.  In the case of target-scoped requests
>    (i.e. TARGET WARM RESET and TARGET COLD RESET), all the
>    commands that are not received, as at the end of step (b),
>    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" (refer section 6.9 on how aborting
>    a specific task can implicitly plug the CmdSN of the task
>    being aborted) at the end of step (b).
> d) Propagates the TMF request to and receives the response
>    from the target SCSI layer.
> e) Takes note of last-sent StatSN on each of the connections
>    in the iSCSI session(s) (one or more) sharing the affected
>    tasks, and waits for acknowledgement of each StatSN (may
>    solicit for acknowledgement by way of a NOP-In). If some
>    tasks originate from non-iSCSI I_T_L nexi then the means by
>    which the target insures that all affected tasks have
>    returned their status to the initiator are defined by the
>    specific non-iSCSI transport protocol(s).
> f) Sends the task set management response to the issuing
>    initiator.
>
> [*] "affected" tasks:
>       ABORT TASK SET: All outstanding tasks for the I_T_L nexus
>                       identified by the LUN field in the ABORT TASK SET
>                       task management function.
>       CLEAR TASK SET: All outstanding tasks in the task set for the LU
>                       identified by the LUN field in the CLEAR TASK SET
>                       task management function.
>       LOGICAL UNIT RESET: All outstanding tasks from all initiators for
>                       the LU identified by the LUN field in the LOGICAL
>                       UNIT RESET task management function.
>       TARGET WARM RESET/TARGET COLD RESET: All outstanding tasks from
>                       all initiators across all LUs that the issuing
>                       session has access to on the SCSI target device
>                       hosting the iSCSI session.
>
>
>
>
>
> _______________________________________________
> Ips mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ips 

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: "Eddy Quicksall" <[email-masked]>
Date: Thu, 2 Jun 2005 10:33:18 -0400

For purposes of understanding this clearly, can you please note the reason 
for each step? I'm not suggesting this note be added to the RFC but it would 
be helpful for this email thread.

Eddy

---

From: "Mallikarjun C." <[email-masked]>
Date: Thu, 02 Jun 2005 10:41:31 -0700

As I earlier noted in my response to Gwendal, there are three main goals 
that motivated us to spec the sequence of steps.  Let me elaborate on 
those.  The three are:

1. Maintaining a single ordered command flow I_T nexus abstraction to 
the target SCSI layer even with multi-connection sessions.
      Target iSCSI processing of a TMF request must maintain the
      single flow illusion - steps c & d on the target behavior
      correspond to this goal.

2. Maintaining a single ordered response flow I_T nexus abstraction to 
the initiator SCSI layer even with multi-connection sessions.
      Target must ensure that the initiator does not see "old" task
      responses (that chronologically preceded the TMF response) after
      seeing the TMF response - step e on the target behavior corresponds
      to this goal.

3. Draining all active TTTs corresponding to affected tasks before the 
TMF is acted on.
      Targets are better off if the TTTs are deterministically retired
      before the affected tasks are terminated.  No need to worry about
      large-sized Data-out PDUs with stale TTTs arriving after the tasks
      are terminated - step b on the target behavior corresponds to this
      goal.

The proposed text caters to these same goals as did the original text - 
except it now covers all TMFs that can impact multiple tasks.

The only other notable thing in step (c) is the "plugging" part - it is 
just an optimization that says if all tasks on the I_T nexus will be 
aborted anyway (as with a target reset), there is no need to wait, the 
target can simply plug all missing CmdSN slots and move on with TMF 
processing.  Goal #1 is still met because target SCSI layer only sees 
ordered commands.

Hope that clarifies it.

Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
StorageWorks Division
Hewlett-Packard MS 5668
Roseville CA 95747
cbm [at] rose.hp.com

Eddy Quicksall wrote:
> For purposes of understanding this clearly, can you please note the 
> reason for each step? I'm not suggesting this note be added to the RFC 
> but it would be helpful for this email thread.
> 
> Eddy
> 
> ----- Original Message ----- From: "Mallikarjun C." <[email-masked]>
> To: <[email-masked]>
>> Responding to my own comment (since I seem to have done such a fine 
>> job of "aborting" this email thread).....
>>
>> allow targets that might even cause silent data corruptions to qualify 
>> as RFC 3720-compliant.
>>
>> replacing the existing section 10.6.2 in RFC 3720 - so the new text 
>> can cover all the TMFs that can impact multiple tasks.  This is 
>> basically a superset of the current 10.6.2 semantics.
>>
>> Comments are welcome.
>>
>> Mallikarjun
>>
>> TARGET WARM RESET, and TARGET COLD RESET Task Management function 
>> requests consists of the following sequence of actions in the

---

From: "Eddy Quicksall" <[email-masked]>
Date: Thu, 2 Jun 2005 20:00:03 -0400

Thank you. That is a very good explanation.

Two things I have always wondered:

1) Is it required (via SAM-2, SPC-2, etc) that the TMF only act on commands 
with lower CmdSN's?
2) Is it necessary to state when the TMF is passed to the SCSI layer? It 
would seem that that is an implementation issue and as long as the target 
can emulate this behavior to the initiator then it should not be specified 
in this spec.

Eddy

----- Original Message ----- 
From: "Mallikarjun C." <[email-masked]>
To: <[email-masked]>
Sent: Thursday, June 02, 2005 1:41 PM
Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET

> 1. Maintaining a single ordered command flow I_T nexus abstraction to the 
> target SCSI layer even with multi-connection sessions.
> 2. Maintaining a single ordered response flow I_T nexus abstraction to the 
> initiator SCSI layer even with multi-connection sessions.
> 3. Draining all active TTTs corresponding to affected tasks before the TMF 
> is acted on.
>>> Responding to my own comment (since I seem to have done such a fine job 
>>> of "aborting" this email thread).....
>>>

---

From: "Mallikarjun C." <[email-masked]>
Date: Tue, 07 Jun 2005 11:31:13 -0700

CmdSNs indicate the chronological ordering relationship of a TMF to 
tasks.  So, it's natural that a TMF should not be able to impact tasks 
from the future.

The specification of TMF hand-off between iSCSI and SCSI is an important 
spec detail not so much for the hand-off itself, but to identify the 
iSCSI protocol actions that must precede the hand-off - in order to 
maintain the single flow abstraction to SCSI.

Mallikarjun

Mallikarjun Chadalapaka

Eddy Quicksall wrote:
> 1) Is it required (via SAM-2, SPC-2, etc) that the TMF only act on 
> commands with lower CmdSN's?
> would seem that that is an implementation issue and as long as the 
> target can emulate this behavior to the initiator then it should not be 
> specified in this spec.
> 
> Eddy
> 
>> As I earlier noted in my response to Gwendal, there are three main 
>> goals that motivated us to spec the sequence of steps.  Let me 
>> elaborate on those.  The three are:
>>
>> The proposed text caters to these same goals as did the original text 
>> - except it now covers all TMFs that can impact multiple tasks.
>>
>> The only other notable thing in step (c) is the "plugging" part - it 
>> is just an optimization that says if all tasks on the I_T nexus will 
>> be aborted anyway (as with a target reset), there is no need to wait, 
>> the target can simply plug all missing CmdSN slots and move on with 
>> TMF processing.  Goal #1 is still met because target SCSI layer only 
>> sees ordered commands.
>>
>> Hope that clarifies it.
>>
>> Mallikarjun
>>
>> Mallikarjun Chadalapaka
>>> reason for each step? I'm not suggesting this note be added to the 
>>> RFC but it would be helpful for this email thread.
>>>
>>> Eddy
>>>