Subject: Re: iSCSI : EnableACA

From: [email-masked]
Date: Fri, 27 Apr 2001 08:24:03 +0300

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 <[email-masked]> on 26/04/2001 20:27:34

Please respond to Santosh Rao <[email-masked]>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   [email-masked], [email-masked]
Subject:  Re: iSCSI : EnableACA

[email-masked] 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: [email-masked] [SMTP:[email-masked]]
> > Sent: Thursday, April 26, 2001 2:22 AM
> > To:   [email-masked]
> > 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 <[email-masked]> on 20/04/2001 22:11:12
> >
> > Please respond to Santosh Rao <[email-masked]>
> >
> > To:   [email-masked]
> > 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
> >
> >
> > [email-masked] 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

---

From: Ralph Weber <[email-masked]>
Date: Fri, 27 Apr 2001 06:59:24 -0500

Julian,

Regarding your discussion with 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.
>
My question is... Exactly which what are the cases where
T10 is NOT considering making ACA behavior available so
that you believe the EnableACA function is necessary in
iSCSI?

My belief is that every behavior that EnableACA covers
but T10 does not needs to be taken to T10 to see if
they can find a better way to extend ACA coverage to
that area.

Thanks.

Ralph...

---

From: Santosh Rao <[email-masked]>
Date: Fri, 27 Apr 2001 14:14:59 -0700

Julian,

My original proposal for this issue stated that ANY exception condition
on an I/O that had the NACA bit set in its control byte of the CDB must
result in ACA being established.

"Any exception condition" would include :
- I/O being aborted by the target due to a LU Reset, Target Reset or
Clear Task Set issued by another initiator.
- I/O being aborted by the initiator through the use of Abort Task.
- QUEUE FULL, BUSY, RESERVATION CONFLICT, etc status returned on the
I/O.

The caveat to this rule is that while ACA is already active, a second
one would not be established.

The point I'm trying to make is :

1) ACA is being used in this context to aid in the preservation of
strict command ordering. Any attempt to enforce strict command ordering
would require initiators to set the NACA bit in the cdb for their I/Os.
Such initiators would be ACA aware and Clear ACA capable.

The argument that initiators may not be able to perform "Clear ACA" and
so need an additional control [thru EnableACA] to prevent ACA from being
established is not applicable, because, such initiators would not set
NACA in their cdb's, and in that case, ACA would not be established.

2) ACA is a LU level construct and iSCSI is changing this granularity to
be a session level construct. For example, initiators could turn on ACA
to only 1 LU on which they had strong ordering requirements.

3) ACA is a ULP construct and any changes, if found necessary, should be
made in the ULP mode pages and not within iSCSI.

- Santosh