Subject: RE: iSCSI: Out of order commands

From: "Julian Satran" <[email-masked]>
Date: Thu, 8 Nov 2001 19:34:41 +0200

Robert,

We are pursuing a very impractical track. Show me please one SINGLE 
advantage for OOO shipping.

Julo

"Robert D. Russell" <[email-masked]>
Sent by: [email-masked]
08-11-01 17:50
Please respond to "Robert D. Russell"

        To:     Julian Satran/Haifa/IBM@IBMIL
        cc:     [email-masked]
        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
[email-masked]
603-862-3774

---

From: "Robert D. Russell" <[email-masked]>
Date: Thu, 8 Nov 2001 14:56:15 -0500

Julian:

> advantage for OOO shipping.

In your message to Mallikarjun, you stressed the need for
the "no deadlock" mechanism and claimed that it was not understood.
I am trying to understand it and the example you gave seems to
me to be wrong.
Please explain.
Thanks,

Bob

> >
> > Mallikarjun,
> >
> > I did not see a SINGLE performance improvement that results from OOO
> > shipping.
> > I would be bad engineering to give away the "no-deadlock" mechanism we
> > have now for nothing.
> > I have also the impression that the point about deadlock that I keep
> > repeating is ignored or not understood.
> 
> 
> 
> I must be misunderstanding something.
>