Re: Avoiding deadlock in iSCSI

[csapuntz@cisco.com]

> I think I agree with the  comment from David Robinson, who said (among
> other things) "...I don't see the issue.".

I'm starting to think that maybe I'm missing something here. :-)

> At least I do not see the issue with a command and a data Asymmetric
> Session.  Perhaps all we have to do is make a rule, that no unsolicited
> data can be sent, before its command is sent AND that unsolicited data must
> be sent in the same order as the commands that reference it.  

The above is a good rule. I agree with it
heartily. Immediate/unsolicited data should probably be stapled onto
the SCSI command.

But I do not believe it is sufficient to prevent problems.

> If that rule
> is followed I do not see the problem. The Data is (or should be) always
> ready to be read off the data connection queue when needed by the command.

Here is the scenario I proposed. This scenario applies to the iSCSI
model as presented in Pittsburg, in which there is only one TCP connection
(shared between commands and data). There is no unsolicited data.

	1) Initiator sends command 1 (WRITE BLOCK)
	2) Initiator sends command 2 (WRITE BLOCK)
	3) Target reads command 1
	4) Target sends RTT to initiator for data in command 1
	5) Target reads from connection and notices comand 2
	6) Target stops reading from connection because it does
	   not have room for command 2
	7) Initiator sends WRITE data for command 1. WRITE data
           is stuck behind command 2 in the stream.


There are basically three points where you can solve the problem:

	Make sure #2 never happens (initiator never overflows a target queue)

	or ...

	Make #6 to be Target drops command 2

	or ...

	Make #7 is Initiator sends data for command 1 on a separate
	   dedicated, solicited-data only TCP connection. Target
           reads data off the dedicated, solicited-data only TCP
           conneciton

-Costa