Subject: Re: iSCSI : EnableACA

From: [email-masked]
Date: Sat, 21 Apr 2001 18:31:07 +0200

Ralph & Santosh,

You are right. I was confused by the NACA and thought that it is again the
CDB bit.
This bit conveys the right information and if it had been a target-wide bit
it would have fit the bill.
Some of the events that have raised the need for the EnableACA are target
wide.

As it is specified today it NornACA is tied to a "device server" (i.e. a
LU) and has many other items that
are LU specific.

I did place the EnableACA in a target wide Page.

It is a hack in the sense it applies only to iSCSI mandated ACA behavior
and it bound to be misinterpreted sooner or later.

Julo

Ralph Weber <[email-masked]> on 20/04/2001 23:19:18

Please respond to [email-masked]

To:   [email-masked]
cc:
Subject:  Re: iSCSI : EnableACA

I like what Santosh is proposing and have big time reservations
about this hack EnableACA bit.  The cases the Julian is trying
to cover with the EnableACA bit should be covered via the
proposal Ed Gardner is supposed to bring to T10 to make Unit
Attention "sticky" and turn things like BUSY status into
CHECK CONDITIONs.

There is one tiny nit in Santosh's proposal.  The bit in the
standard INQUIRY data is called NormACA, not NACA.  NACA is
the bit in the CDB, only.

Thanks.

Ralph...

Santosh Rao wrote:

>
> 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.
>
>  ++++

---

From: [email-masked]
Date: Sat, 21 Apr 2001 17:51:54 +0200

Santosh,

You read it wrong. It is all about initiators that do not have the right
support for ACA.
The will want to prevent new iSCSI target to act in their canonical manner
using a tinny piece of code in the iSCSI miniport or low-level driver.

Julo

Santosh Rao <[email-masked]> on 20/04/2001 21:11:12

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

To:   [email-masked]
cc:
Subject:  iSCSI : EnableACA

Julian,

- Santosh

[email-masked] wrote:

> a) An initiator knows whether a target supports ACA from the NACA bit in
> initiator can use it by setting the NACA bit in the CDBs it sends. There
> b) The ACA is a SCSI ULP concept and iSCSI should not be negotiating its
> 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
> 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

 ++++
 - santoshr.vcf

---

From: [email-masked]
Date: Thu, 26 Apr 2001 09:22:29 +0300

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

To:   [email-masked]
cc:

Julian,

- Santosh

 ++++
 - santoshr.vcf

---

From: [email-masked]
Date: Sun, 29 Apr 2001 08:25:18 +0300

comments in text - Julo

Santosh Rao <[email-masked]> on 28/04/2001 23:46:02

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

> What you are suggesting is that during reset the target examines all CDBs
> from all initiators.
> Doesn't seem very practical to me.

Julian,

The target needs to walk through its task set to abort each I/O while
processing one of Clear Task Set, LU Reset, Target Reset, Abort Task Set.
On finding an I/O in its task set which has the NACA bit set, it could
establish ACA.

> What about a command in flight (that
> was the first that had a NACA bit)?

Such I/Os would be errored back with "ACA Active" SCSI Status.

+++ what if none of the preceding had a Naca bit? +++

> It looks like ED might solve the problem for us making UA behave ACA
> like.

I had some questions on this (which Ralph might help us with).
If the UA is going to be a persistent condition [like ACA], will it not
require a second mechanism similar to Clear ACA to clear the UA ? If this
is correct, do we need to invent 2 mechanisms to deal with a similar
requirement ? Could we apply the proposal made in my earlier mail to solve
all exception conditions on a strongly ordered command [that sets NACA in
its CDB] by generating ACA.
[Note that we also need to solve this problem when an I/O active in a task
set receives an Abort Task.]

Any comments from the T10 experts would be appreciated.

> And EnableACA is not per session (although at a point I intended it to
be).

This may be no longer relevant if we are going to allow T10 to solve this
for us. Per my understanding though, all login keys governed session
control options [and not LU options]. Hence, my comment regarding session
granularity. One way to solve this would have been to move EnableACA to
a mode page only control option.

Thanks,
Santosh

> Santosh Rao <[email-masked]> on 28/04/2001 00:14:59
>
> To:   Julian Satran/Haifa/IBM@IBMIL, [email-masked]
> cc:   [email-masked]
> Ralph Weber wrote:
> > 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.
>
> 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 Rao
Software Design Engineer,
HP, Cupertino.
email : [email-masked]
Phone : 408-447-3751
#################################

---

From: [email-masked]
Date: Sun, 29 Apr 2001 09:22:30 +0300

Santosh - get through every CDB at a reset is not very practical - and I am
afraid it will also be considered bad engineering - you want to clean
everything up as it might be in a mess.

Also the behaviour is inconsistent for commands in flight and those queued
already :

- for those queued already it is ACA if any in the queue is ACA (at least
from your description)
- for those in flight only if the first is ACA

Julo

Santosh Rao <[email-masked]> on 29/04/2001 08:40:44

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   [email-masked] (Santosh Rao)
Subject:  Re: iSCSI : EnableACA

Julian,

The point I'm trying to make is that if there were no prior NACA I/Os
in the task set, those I/Os had no ordering dependencies. In that case,
ACA is not required. CAC is sufficient.

In the case where ordering of I/Os is required, such I/Os expect ACA to be
established on an error and they have their NACA bit set.

IOW,
1) no NACA in task set => no ordering required => use CAC on error

2) NACA in task set => some I/Os require ordering => use ACA on error

3) First NACA I/Os arrive after CAC => process normally (I/Os prior to CAC
did not expect ordering).

The above is all based on the fundamental model that I/Os that expect
ordering MUST set the NACA bit in their CDBs. Hence, ACA is not required
to be established when the task set does not contain a NACA I/O.

Regards,
Santosh

>
> Sure - the unit attention is cleared by the first and all the others get
> true - for non-ACA it is OK
> for ACA we wanted all to be dropte up to explicit reset.
>
> Julo
>
> Santosh Rao <[email-masked]> on 29/04/2001 00:59:42
>
> To:   [email-masked] (ips)
> cc:   Julian Satran/Haifa/IBM@IBMIL
> Oops. I believe your question was regarding the first NACA set CDB
> in-flight and not yet in the task set at the time of the task mgmt cmd.
>
> Such a scenario implies the I/Os prior to that first NACA set I/O would
> have had no ordering constraints. In this case, no ACA is established for
> the task mgmt cmd prior to the first NACA I/O. [CAC is established.]
>
> The CAC is cleared on the next I/O [other than INQUIRY and REPORT LUNS]
> that arrives after CAC was established. Subsequent arrival of a NACA set
> I/O is processed normally and no loss of ordering occurs in this case.
>
> Did I miss something about this scenario (?)
>
> Regards,
> Santosh
>
> --