RE: iSCSI: Why is ACA optional?

[Charles Monia <cmonia@NishanSystems.com>]

Hi Julo:

See below.

> -----Original Message-----
> From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com]
> Sent: Thursday, November 30, 2000 11:55 AM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: Why is ACA optional?
> 
> 
> 
> 
> Charles,
> 
> It is good enough if it is mandated for new devices - those 
> are likely to
> appear with native iSCSI -
> with a wording in the SHOULD class (strongly recomended).
> 

In T10, "should" doesn't have the force of a requirement. A device that
doesn't implement the feature can't be declared non-compliant.  What's more,
strongly recommending an option doesn't even guarantee that the majority of
devices will implement the feature.  In such cases, the buyer's only
leverage is the product purchase spec, hoping in the meantime that the
feature becomes a de-facto requirement of the market.  Would that meet your
needs?

As an aside, it's been suggested that iSCSI devices need only support ACA if
they implement command queuing.  That sounds reasonable to me.

Charles
> Regards,
> Julo
> 
> Charles Monia <cmonia@NishanSystems.com> on 30/11/2000 21:29:45
> 
> Please respond to Charles Monia <cmonia@NishanSystems.com>
> 
> To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> cc:
> Subject:  RE: iSCSI: Why is ACA optional?
> 
> 
> 
> 
> Hi Julo:
> 
> A blanket requirement for mandatory ACA support would make almost all
> legacy
> devices noncompliant.  I don't think the T10 community would 
> be willing to
> support that any time soon.
> 
> Charles
> > -----Original Message-----
> > From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com]
> > Sent: Wednesday, November 29, 2000 9:21 PM
> > To: ips@ece.cmu.edu
> > Subject: RE: iSCSI: Why is ACA optional?
> >
> >
> >
> >
> > Charles,
> >
> > That is probably the path we should be taking although I
> > wonder why would
> > T10 not mandate as it
> > as this thing affects all interconnects. We might then (as
> > with the name
> > mapping) see it happen in T10.
> >
> > Regards,
> > Julo
> >
> > Charles Monia <cmonia@NishanSystems.com> on 30/11/2000 00:06:29
> >
> > Please respond to Charles Monia <cmonia@NishanSystems.com>
> >
> > To:   "Ips (E-mail)" <ips@ece.cmu.edu>
> > cc:
> > Subject:  RE: iSCSI: Why is ACA optional?
> >
> >
> >
> >
> > Hi Julo:
> >
> >
> >
> > > -----Original Message-----
> > > From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com]
> > > Sent: Wednesday, November 29, 2000 11:18 AM
> > > To: ENDL_TX@computer.org
> > > Cc: ips@ece.cmu.edu
> > > Subject: Re: iSCSI: Why is ACA optional?
> > >
> > >
> > >
> > >
> > > Ralph,
> > >
> > > That is an interesting argument.
> > >
> > > However, now that disks have become more complex and can
> > > queue tasks how
> > > would you
> > > handle having one task rejected because the queue was full
> > > and the next
> > > (still in flight) accepted because
> > > some slot became available?
> > >
> >
> > The case you mention certainly addresses most but not all
> > such occurences.
> > There are other transient exceptions, such as commands that
> > terminate with
> > a
> > BUSY or ACA ACTIVE status, that have the same effect but do
> > not themselves
> > result in an ACA condition.
> >
> > > And this might even happen inside the host (possibly a large
> > > SMP) that with
> > > SMP would not have to care coordinating tasks but without ACA
> > > will have to
> > > strictly serialize access.
> > >
> > > IMHO TODAY not mandating ACA is a mistake (IBM 360 disk
> > > controllers had it
> > > 30 years ago for the very reason I quoted).
> > > I any case iSCSI can do little to ease the pain - except to
> > > point out to
> > > those that plan using disk subsystems without ACA to rely 
> on status
> > > numbering and issue commands one by one.
> > >
> >
> > I believe iSCSI always has the option of making ACA support
> > mandatory (in
> > the same way that autosense support is mandatory).  If so,
> > for practical
> > reasons it will be up to the initiator's iSCSI stack to do so
> > in a way that
> > is transparent to the parts of the I/O driver stack above the
> > iSCSI layer.
> >
> > Charles
> >
> >
> >
> 
> 
>