Re: 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