Re: iSCSI : EnableACA

[julian_satran@il.ibm.com]

Santosh,

The task management functions for iSCSI contain a description the behaviour
I am talking about.
This was also subject to a long discussion on the list that included the
need for ACA behaviour for things like
task-set full, busy etc. - not considered for ACA. For the later T10 is
handling making ACA behaviour
available.

Julo

Santosh Rao <santoshr@cup.hp.com> on 26/04/2001 20:27:34

Please respond to Santosh Rao <santoshr@cup.hp.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   Black_David@emc.com, ips@ece.cmu.edu
Subject:  Re: iSCSI : EnableACA




Black_David@emc.com wrote:
>
> > What you are suggesting is that in all cases in which iSCSI would
require
> > the target to enter ACA (after a LU reset or a target reset) look
forward
> > in the queue and enter ACA only if it finds a CDB marked NACA? (and
that
> > includes commands in flight).

Julian,

I am not suggesting any such thing. ACA is only established when the
logical unit completes a command [that had the NACA bit set in its
control byte in the CDB] with a CHECK CONDITION status.

ACA is not established after a LU Reset or Target Reset. On the
contrary, a target reset or LU Reset would clear any existing CAC or
ACA.

- Santosh


>
> Ok, so why is iSCSI requiring ACA in addition to Unit
> Attention for Clear Task Set, LU Reset and Target Reset?
> In all cases, we're dealing with Initiators whose tasks
> are cleared as a consequence of another Initiator
> issuing the appropriate task management command.
> SAM2 only requires Unit Attention.
>
> --David
>
> > -----Original Message-----
> > From: julian_satran@il.ibm.com [SMTP:julian_satran@il.ibm.com]
> > Sent: Thursday, April 26, 2001 2:22 AM
> > To:   ips@ece.cmu.edu
> > Subject:      Re: iSCSI : EnableACA
> >
> >
> >
> > Santosh,
> >
> > How about a third confusing response?
> >
> > We have introduced the EnableACA (per LU) to enable an initiator
unwilling
> > to use it to disable it at the target for this specific Initiator.
> >
> > NormACA - the enquiry bit - indicates support for ACA by the target
device
> > server but is a "read-only" bit.
> >
> > What you are suggesting is that in all cases in which iSCSI would
require
> > the target to enter ACA (after a LU reset or a target reset) look
forward
> > in the queue and enter ACA only if it finds a CDB marked NACA? (and
that
> > includes commands in flight).
> >
> > Or to enter ACA only when it finds such a command (sort of "soft ACA")?
> >
> > Both of them sound wrong and complex.
> >
> > Julo
> >
> > Santosh Rao <santoshr@cup.hp.com> on 20/04/2001 22:11:12
> >
> > Please respond to Santosh Rao <santoshr@cup.hp.com>
> >
> > To:   ips@ece.cmu.edu
> > cc:
> > Subject:  iSCSI : EnableACA
> >
> >
> >
> >
> > Julian,
> >
> > Would the following not satisfy the requirements for dealing with this
> > ACA issue :
> >
> > 1) Initiators determine the target support for ACA through the NACA bit
> > in the INQUIRY response. (Assuming iSCSI targets have implemented ACA
in
> > good faith, this would be supported.)
> >
> > 2) Initiators set the NACA bit in the CDBs of commands that need strong
> > ordering. (This could be a small subset of the I/O traffic to one or
> > more LUNs within the session and not required for all the I/Os in that
> > session.)
> >
> > 3) Any exception condition on a SCSI I/O, for which the NACA bit was
set
> > results in ACA being established.
> > Thus, ACA would only be applied if some I/O traffic that required
strong
> > ordering was affected by the exception condition.
> >
> > 4) Since the initiator is ACA capable based on its usage of the NACA
> > bit, it should also be capable of performing the desired Clear ACA to
> > recover from this condition.
> >
> > Such an approach would only apply ACA and its corresponding recovery
> > when some strongly ordered I/O encountered an exception condition,
> > rather than applying ACA on a session granularity.
> >
> > To summarize, the above approach allows :
> > - ACA to be turned on/off for a subset of I/Os headed to a LUN
> > - ACA based recovery only used where needed.
> > - Keeps iSCSI ACA un-aware and rightly so, since this is a property of
> > the SCSI ULP.
> > - Avoids applying ACA recovery on a session granularity.
> >
> > What am I missing here (?). Why is an EnableACA needed ?
> >
> > - Santosh
> >
> >
> > julian_satran@il.ibm.com wrote:
> >
> > > All references to
> > > EnableACA are redundant and should be removed for the following
reasons
> > > :
> > >
> > > a) An initiator knows whether a target supports ACA from the NACA bit
in
> > > the INQUIRY response. When a target indicates support for ACA, the
> > > initiator can use it by setting the NACA bit in the CDBs it sends.
There
> > > is NO need for any sort of negotiation of this behaviour above and
> > > beyond what is already provided thru SCSI mechanisms.
> > >
> > > b) The ACA is a SCSI ULP concept and iSCSI should not be negotiating
its
> > > use or lack thereof. This is done thru the NACA bit in CDBs.
> > >
> > > c) (As a side note, the description of EnableACA on pg 127 refers to
its
> > > presence in the lun control mode page, but it is actually present in
the
> > > protocol specific port page.)
> > >
> > > d) ACA is a LUN-level (more an I/O level) control option. It MUST NOT
be
> > > negotiated on a per-session basis. SCSI allows initiators to request
ACA
> > > behaviour on a per I/O basis through the use of NACA bit in the CDBs.
> > >
> >
> >  +++ We have required ACA to be supported by all new iSCSI targets and
> >  several
> >  actions require the target to enter ACA state.
> >  It was brought to our attention that many initiators will not react
> >  properly to a
> >  target entering ACA state (not do the reset).
> >  The EnableACA bit and key are meant to enable an initiator to control
> > this
> >  iSCSI specific ACA behaviour.  This behaviour is related to
> > asynchronous
> >  events and is not controlled by the NACA CDB bit.
> >
> >  ++++
> >  - santoshr.vcf
> >
> >
 - santoshr.vcf