Re: Avoiding deadlock in iSCSI

[csapuntz@cisco.com]

> 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