|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: Out of order commandsRobert, We are pursuing a very impractical track. Show me please one SINGLE advantage for OOO shipping. Julo "Robert D. Russell" <rdr@mars.iol.unh.edu> Sent by: owner-ips@ece.cmu.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
Home Last updated: Thu Nov 08 15:17:37 2001 7655 messages in chronological order |