RE: iSCSI: Out of order commands

["Julian Satran" <Julian_Satran@il.ibm.com>]

Nothing wrong with your reasoning. Only that a with ordering in place a 
designer might commit for it's cumulative set of resources (TCP windows + 
application buffers) while for unordered delivery it can commit only the 
application resources.

And I did not hear back from you about any specific reasons to do so 
(neither initiator nor targets get gaster).

Julo




"Robert D. Russell" <rdr@mars.iol.unh.edu>
08-11-01 17:50
Please respond to "Robert D. Russell"

 
        To:     Julian Satran/Haifa/IBM@IBMIL
        cc:     ips@ece.cmu.edu
        Subject:        RE: iSCSI: Out of order commands

 

Julian:

> However allowing initiators to ship them out of order creates a 
> potential deadlock that does not appear otherwise.
> 
> If a target is missing a command in a queue (and there are no errors) 
then
> this command is bound to be first on some connection under the current 
set 
> of rules.
> 
> If we allow OOO shipping then the missing command can be somewhere 
> "inside" the window on some connection and if the target has just filled 

> his queue and has room in the staging buffer only for the command it is 
> waiting for and that command happens to be the first to pass to SCSI you 

> have a deadlock.


I must be understanding something.

Your example is certainly correct if the target has no control
over the number of commands sent to it by the initiator.
But the target does control this number through the MaxCmdSN field.
For the scenario you are describing to occur, wouldn't it be
necessary for the target to advertize a MaxCmdSN value bigger than
it actually has resources to handle?

It seems to me that if a target can only handle x new commands,
then its queueing capacity is x, and in the SCSI Response PDU it
should set MaxCmdSN = (ExpCmdSn + x - 1), in accordance with the
formula in section 2.2.2.1.  This in turn controls the number of
commands the initiator can send, and thus prevents the incoming
commands from overfilling the target's queue.

So isn't the deadlock caused by a broken target?
Isn't the target advertizing a queueing capacity greater than it
actually has and isn't that the cause of the deadlock?

An alternative explanation of the deadlock might be that the
target is advertizing the correct MaxCmdSN, but the initiator is
sending commands beyond what it is allowed to send.

However, in this case the target should silently ignore any
non-immediate command outside the allowed range.
For the deadlock to occur, wouldn't the target have to be queuing
commands outside the allowed range instead of ignoring them?

So in this case too, the target is broken and that is what causes
the deadlock.

Where am I going wrong in this reasoning?

Thanks,
Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774