RE: Fast multi-task abort model

Mallikarjun,

I am sort of missing the point. Are you saying that the
Mode Control Page belongs to the transport layer?
It is not sufficient to know the active TTTs,
task-session-connection affinity, and LUN-TTT association.

You have to know the TAS, TST and Qerr bit settings
to determine if the commands are to be aborted without
response, with response, no impact, blocked.

So either the transport layer has to be know the Mode
Control Page or the SCSI layer has to explicitly
trigger the abort - it does not say send an async PDU,
but something like abort all commands on the lun and
the nexus receiving tmf was xxxx.

Also as you say the target does not progress beyond step
1 - but step 1 is where the commands start to get aborted
(immediately) - even if the tmf is not supported by the
SCSI layer?

BTW the new mechanism is not only useful for getting a
common understanding between target and initiator for
tmf commands, but may be useful for Unit Attention
conditions as well (without having to implement SPC-3).

Somesh

>-----Original Message-----
>From: [email protected] [mailto:[email protected]] On 
>Behalf Of Mallikarjun C.
>Sent: Thursday, December 08, 2005 11:28 AM
>To: [email protected]
>Subject: Re: [Ips] Fast multi-task abort model
>
>
>Hi Somesh,
>
>Thanks for the review.
>
>The new model does not require any additional
>knowledge in the iSCSI layer than the layer already
>has, and SCSI layer should not get involved in
>generating iSCSI Async PDUs either.   The model
>intends that the iSCSI layer decides when to generate
>an Async PDU based on its standard state information
>(active TTTs, task-session-connection affinity,
>LUN-TTT association). 
>
>The new (or the old) model does not require iSCSI
>layer to know about TMF-support-capabilities of the
>back-end.  SCSI-level TMF Response is generated by the
>SCSI back-end as always.  If the back-end does not
>support a TMF function, I expect none of the steps
>after #1 will happen.
>
>You're right that the Nop-Out ack/timeout is only for
>the purpose of recovering buffer resources behind
>affected TTTs.
>
>Hope that clarifies the model description.
>
>Mallikarjun
>
>
>
>
>
>--- Somesh Gupta <[email protected]>
>wrote:
>
>> (My first attempt did not seem to make it through.
>> Apologies
>> if people see a duplicate.)
>> 
>> 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?
>> 
>
>
>--
>Mallikarjun
>
>
>Mallikarjun Chadalapaka
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam?  Yahoo! Mail has the best spam protection around 
>http://mail.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