Subject: RE: iSCSI : EnableACA

From: [email-masked]
Date: Thu, 26 Apr 2001 17:06:00 +0300

The reason to ask for ACA is to reestablish the order intended by the
issuing initiator including commands in flight at the time of the reset.
As the issuing initiators are not aware of the reset. The order in which
things will be executed for them may be important and they may want to
reissue some commands ahead of the commands in flight.

Julo

[email-masked] on 26/04/2001 10:30:40

Please respond to [email-masked]

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

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

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

---

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

[email-masked] wrote:
> 
> David,
> 
> I read Bob's mail and my interpretation is similar to his. However I think
> that SPC explicitly states that different transports are free to interpret
> and make use of this page as they find appropriate.
> 
> I have a hard time understanding Santosh's objection as it does not refer
> to the reason the EMDP is there but to the way it is written in FCP (not
> iSCSI).

Julian,

As has been stated earlier, EMDP allows control over the order in which
the target requests outbound data or sends inbound data. EMDP can be
used by initiators to control this order and turn off out-of-order R2T
requests [as well as turn off out of order read data pdus].

This is a useful control option and is already provided by other SCSI
transports. What good reason exists to deny this provision in iSCSI ?

Also, I have some concerns about the ambiguous definition of DataOrder.

Per the spec :
"DataOrder=<yes|no> 
    
The default is yes but targets MAY support no. No is used by iSCSI to
indicate that the data PDUs can be in any order (EMDP = 1). Yes is used
to indicate that incoming data PDUs have to be at continuously
increasing addresses (EMDP = 0)."

Based on the above definition wording :

a) How is DataOrder interpreted for WRITE I/Os ?
b) Is the ordering across the entire SCSI command or a subset of the I/O
? If so, what constitutes this subset ?

Different implementors can arrive at different interpretations reading
the above definition !

- Santosh