Re: Avoiding deadlock in iSCSI

[julian_satran@il.ibm.com]

Well - if the targets enters ACA - that state can be reset only explicitely
and then you resend the commands in order.

Julo

csapuntz@cisco.com on 12/09/2000 08:32:44

Please respond to csapuntz@cisco.com

To:   Jim McGrath <Jim.McGrath@quantum.com>
cc:   ips@ece.cmu.edu, csapuntz@cisco.com (bcc: Julian Satran/Haifa/IBM)
Subject:  Re: Avoiding deadlock in iSCSI





> Note that SCSI targets, when faced with getting a command queue full, do
not
> stop reading from the interconnect.  If more commands are received then
they
> respond with a QUEUE FULL status.  If data is received then they receive
> that data without regard for the status of the command queue (as long as
it
> is data for an already queued command).  This eliminates the potential
for
> deadlock between command and data queues.

Jim,

I believe there is problem with the current SCSI behavior. Consider the
following scenario for a host with a pathological queue of 1


     1) Initiator sends command 1 (ORDERED attribute)
     2) Initiator sends command 2 (ORDERED attribute)
     3) Initiator sends command 3 (ORDERED attributge)
     4) Target reads command 1
     5) Target reads command 2
     6) Target returns queue full for command 2
     7) Command 1 completes
     8) Target reads command 3
     9) Target executes command 3

We have just violated the ordering constraints of the application by
doing command 3 before command 2.

> Potentially you can have a situation where multiple commands already at
the
> target have only part of their data transmitted, with the remainder still
at
> the initiator(s), and then run out of buffer space for data.  If the
target
> uses a credit model to pace the reception of data, it can also make sure
> this never happens.  Unsolicited data, even for commands already queued,
can
> end up creating this deadlock - which is why unsolicited data systems
either
> have to have a tight limit on the resources it can use (e.g. low login BB
> credit in Fibre Channel terms) or some sort of clean (i.e. not IO
> terminating) rejection mechanism from target to initiator (like in USB).

Unsolicited data is NOT a problem with the current iSCSI spec. We allow
the target to always drop data and request data transfers
with an RTT.

-Costa