RE: Avoiding deadlock in iSCSI

[julian_satran@il.ibm.com]

Peter,

I am on the road - and had barely time for a short answer. I made the same
assumption like you that this is a Check Condition.

Issuing command one at a time is not a decent option. One-at-a-time is
already provided by chaining and ordered set where created to enable you,
unlike chaining,  to hide the latency of command transport and setup.

Otherwise who needs them? Why go at such length to deliver things in order.

I see it really as a T10 issue.

Regards,
Julo

Peter Johansson <PJohansson@ACM.org> on 14/09/2000 16:52:01

Please respond to Peter Johansson <PJohansson@ACM.org>

To:   IP Storage <IPS@ece.cmu.edu>
cc:    (bcc: Julian Satran/Haifa/IBM)
Subject:  RE: Avoiding deadlock in iSCSI




At 08:42 AM 9/13/00, julian_satran@il.ibm.com wrote:

>Where would you suggest it should be done without violating layering
>constraints?

Your query is a bit laconic, Julo, but to put it in the context of how to
preserve ordering in the event of a queue full condition, I misspoke
earlier.

I was under the mistaken impression that a QUEUE FULL condition resulted in
a CHECK CONDITION and the concomitant creation of ACA.

Jim McGrath pointed out that this is not so. Of the remedies he outlined,
of course it's possible for the initiator to refrain from issuing more than
one ordered task at a time. This is reasonable for many environments, for
example those in which the preponderance of tasks are unordered with the
occasional need of an ordered task to fence some synchronization point. In
other environments, either purely ordered or one in which a high number of
tasks are ordered, this could be inefficient.

I like Jim's suggestion of a QACA bit because it does not lump the QUEUE
FULL condition together with other ACA events. It wasn't clear whether Jim
was referring to a QACA bit in a mode page or in a CDB or both.

Although this is, strictly speaking, a T10 matter, it involves interactions
with the iSCSI protocol's capabilities and limitations and therefore would
benefit from participation by this working group.




Regards,

Peter Johansson

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

PJohansson@ACM.org