Subject: Re: iSCSI : EnableACA

From: [email-masked]
Date: Sat, 28 Apr 2001 16:50:53 +0300

What you are suggesting is that during reset the target examines all CDBs
from all initiators.
Doesn't seem very practical to me.  What about a command in flight (that
was the first that had a NACA bit)?
It looks like ED might solve the problem for us making UA behave ACA like.

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

Julo

Santosh Rao <[email-masked]> on 28/04/2001 00:14:59

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

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

Ralph Weber wrote:
>
> 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.

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
 - santoshr.vcf

---

From: Santosh Rao <[email-masked]>
Date: Sat, 28 Apr 2001 13:46:02 -0700 (PDT)

> 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

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

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

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
Software Design Engineer,
HP, Cupertino.
email : [email-masked]
Phone : 408-447-3751
#################################

---

From: Santosh Rao <[email-masked]>
Date: Sat, 28 Apr 2001 14:59:42 -0700 (PDT)

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

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