|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI:flow control, acknowledgement, and a deterministic recoveryJulian, If you do not reject commands pending within the sequencer, then you will need to log these out of sequence events to ensure the command taken out of sequence will not cause a hole later. You could allow an exception for window size but if you are attempting to issue many of these urgent commands, then a single exception does not provide much flexibility. Should you reject all prior commands within the sequencer, there is no issue regarding the logging of these out of sequence commands. Should there be a sequence of urgent commands, by flagging the first such command forces the window to be cleared to allow these urgent commands their immediate deployment. This rejection technique also has the advantage of deleting command holes without timeouts should there be a problem with a connection. This technique supplemented with SNACK appears to provide a rather immediate recovery again without reliance on the SCSI layer. As there should already be code ready to handle rejected commands, using this mechanism does not add code and allows the transport to use this very simple mechanism. This also does not depend on the target within the SCSI layer to handle these out of sequence events so there is less likelihood of needing the SCSI layer tailored to use iSCSI. While placing this immediate function into a flag ensures that such a command is acknowledged eventually if rejection is not used and immediately if commands are rejected, this flag however provides the vital information of command placement to prevent such a command from applying after subsequent commands for without this flag there is no assurance when such a command is received. Doug > The main reason for selecting 0 and not a flag for immediate delivery was > to enable immediate delivery even when the command window is closed. > > However we can achieve the same effect by using an immediate flag and > ausing the current CmdSN without advancing it. With this we get a > reference to where in the stream the command where supposed to act if the > stream order is important. All commands that reached the target having > CmdSN less than the immediate CmdSN where sent before our command and all > those with a number equal or higher where sent after. Immediate commands > are the only ones that can have a CmdSN higher (by 1) that the allowed > window. > > Julo > > >
Home Last updated: Tue Sep 04 01:05:08 2001 6315 messages in chronological order |