RE: Fast multi-task abort model

Somesh,

I do not see anything new per se.  The new abort model
does not change: a) the SCSI-iSCSI interface specific
to the implementation (Async can be keyed off the same
API touch points), b) division of labor between iSCSI
and SCSI layers (e.g., mode pages etc.), and  c) state
information maintained at the iSCSI layer (standard
state information I listed earlier).

You however have a valid point on the text when you
flagged "immediately" in step #1 - I now see how it
can be read.  Without going into implementation
specifics even while keeping the text precise, I
suggest changing:

1. Target iSCSI layer initiates the termination
proceedings on all affected tasks immediately - this
may involve interacting with the local SCSI layer.

to:

1. Target iSCSI layer initiates the termination
proceedings on all affected tasks via notifying the
local SCSI layer.


I hope that addresses your concern.

Thanks.

Mallikarjun


--- Somesh Gupta <[email protected]>
wrote:

> 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

__________________________________________________
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