Re: Fast multi-task abort model

Where can I find the latest draft on this subject?

Eddy

----- Original Message ----- 
From: "Somesh Gupta" <[email protected]>
To: "IPS" <[email protected]>
Sent: Wednesday, December 07, 2005 3:43 PM
Subject: RE: [Ips] Fast multi-task abort model


The discussion prompted me to take a closer look at
the fast multi-task abort model. In principal, I agree
that the new async PDU helps the target and initiator
reach a common understanding of which tasks have
been cleared, and stop processing them.

However, I think the language of the proposal puts
too much knowledge in the target transport layer -
the language implies that the target transport layer
is managing the task set for a LUN - it is responsible
for determining which initiators have active tasks on
a specific LUN, and which tasks these are, what their
disposition is - and for sending a TMF response (and which
TMFs are supported and what the back-end impact of each is).

It is not so simple since the values of the TAS, TST and
Qerr bits really determine the actions.

There is some unavoidable interaction/modification of
the SCSI layer to handle this situation correctly -
because only the SCSI layer knows whether for the cleared tasks
a. the initiator is really not expecting anything
   (the nexus is the same as which received the tmf command)
b. should be sent an explicit status of ABORTED BY ANOTHER
   INITIATOR
c. No impact
d. Needs to be cleaned up through the asynch notification
   mechanism (different nexus, TST=0:Qerr=01b;TAS=0)
c. Whether the initiator is likely to be dead (LUN Reset
   with reserve/release model or equivalent behavior in
   persistent reservation model)

In other words, the asynch PDU must be explicitly triggered
by the SCSI layer on each impacted Nexus - if adding the
asynch PDU becomes an issues, we can use a new response
code which would be sent for every command. In any case,
the statsn acknowledgement rule should help the initiator
and target flush all impacted commands in the pipe, and
have a common understanding of what is impacted.

Bill makes a very valid point about the real world situation
of clusters. Shouldn't the SCSI layer be able to send a
response for the TMF when it has triggered the asynch PDU on
each of the Nexuses (is it Nexi?). The acknowledgement or
time-out is only for the purposes of recovering the buffers?

>-----Original Message-----
>From: [email protected] [mailto:[email protected]] On 
>Behalf Of Mallikarjun C.
>Sent: Tuesday, December 06, 2005 3:13 PM
>To: IPS
>Subject: Re: [Ips] Fast multi-task abort model
>
>
>>Mark
>> the tcb as 
>> terminated, then wait for the TTs to complete. When
>> they are done, 
>> throw the whole thing out.
>
>Reasonable, and this is in abstract what the new
>proposal does.
>
>RFC 3720 does not explicitly say "wait for TTTs to
>complete even after TMF is completed".  The only
>default interpretation of the 3720 text today would be
>to invalidate the TTTs along with the buffer
>associations when a task is "terminated" and the TMF
>completion is generated.  An invalid TTT/STag is in
>fact a problem for at least two reasons - 
>
>a) All Data-Out PDU (with the now invalid TTTs) are
>protocol errors that should be Reject'ed.
>b) Any DDP tagged data segment to an invalid STag
>immediately takes the connection down (for
>iSCSI/iSER).
>
>What I am suggesting in the new proposal is that there
>be an explicit event to conclude the "waiting for TTTs
>to complete" for a target at the iSCSI control
>protocol level (not at the Datamover level).  That new
>event is the reception of the Nop-Out ack'ing the new
>Async PDU.  And that brings us to the new proposal.
>
>I think the 3720 text is self-consistent (although it
>isn't the most efficient).  Simply scratching the TTT
>cross-nexus requirement off the current text, IMHO, is
>not the right thing. We need to specify the new
>initiator and target semantics in the absence of that
>requirement, and that's what the fast multi-task abort
>proposal attempts.
>
>Mallikarjun
>
>
> 
>
>--- William Studenmund <[email protected]>
>wrote:
>
>> On Dec 1, 2005, at 4:01 PM, Mallikarjun C. wrote:
>> 
>> >> Why does it need to be cross-nexus, other than
>> the
>> >> fact that RFC 3720
>> >> says it should be?
>> >
>> > There's a good rationale behind RFC 3720 text:
>> >
>> > TMF cannot complete until all affected tasks are
>> > terminated on the target per SAM.  Receiving stale
>> > data after tasks are terminated is a problem. 
>> Waiting
>> > for all active TTTs of all affected tasks (same
>> and/or
>> > other nexus) to finish was thus the adopted
>> approach
>> > to avoid stale data for any affected task.
>> 
>> Shouldn't we leave how the target avoids/copes with
>> stale data to the 
>> target?
>> 
>> I guess I don't see how receiving "stale" data after
>> a task has been 
>> terminated is a problem. Specifically I don't see
>> how it's a problem to 
>> receive data you knew was in-flight at the moment
>> the termination 
>> happened. You have your tcb structure (however you
>> have it laid out), 
>> and you know what TTs are associated with it. Mark
>> the tcb as 
>> terminated, then wait for the TTs to complete. When
>> they are done, 
>> throw the whole thing out.
>> 
>> > What the new proposal does is to make receiving
>> stale
>> > data after task terminations a non-problem - via a
>> > separate accounting scheme and new target
>> semantics.
>> 
>> And I think this is a good thing. However I still
>> think we need to 
>> abandon the inter-nexus TT wait for the old scheme.
>> 
>> Take care,
>> 
>> Bill
>> 
>> 
>
>
>
> 
>__________________________________________ 
>Yahoo! DSL - Something to write home about. 
>Just $16.99/mo. or less. 
>dsl.yahoo.com 
>
>
>_______________________________________________
>Ips mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/ips
>




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


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