Re: Avoiding deadlock in iSCSI

[julian_satran@il.ibm.com]

Costa,

The case you are describing is not a deadlock. If a target has no room for
commands it
can reject them and enter ACA.
A real deadlock (i.e. target has resources but can't use them properly) can
appear only if
unsolicited data appear out-of-order.  In this case a good target will
fence-off the specific initiator (disconnect and wait for administrative
action).

I think that both symmetric and asymmetric models behave well against a
good initiator.
The only think we should make sure (and I am not sure that we are though
it) is that
a bad initiator can't stop forever a good initiator - or do him serious QoS
harm (something that looks like a denial of service). And taking into
account that initiators can be
software driven desktops we should be really careful here.

Julo



csapuntz@cisco.com on 12/09/2000 08:28:03

Please respond to csapuntz@cisco.com

To:   John Hufferd/San Jose/IBM@IBMUS
cc:   ips@ece.cmu.edu, csapuntz@cisco.com (bcc: Julian Satran/Haifa/IBM)
Subject:  Re: Avoiding deadlock in iSCSI





> 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