|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: Avoiding deadlock in iSCSIFrom the discussion going on the symmetric versus asymmetric model and dead lock avoidance, here is a proposal that tries to combine (as far as possible...) the advantages of both models. The proposal is a slightly modified symmetric model where the symmetric model incorporate an idea of the current asymmetric model. This idea is that the initiator indicates to the target on which connection the next command in order arrives. The asymmetric model does that using an extra connection transporting the commands, and for each command in the header there is the connection number where the data will come. Description of the proposal: --------------------- In the command header a field is added. This field "next connection" indicates the TCP connection (connection id) in the session on which the next command will arrive. This field builds a linked list of commands across the several symmetric connections of the session. The first time the initiator posts a command, it determines the connection on which it post the command and the connection on which it will post the next command. Then for each command the initiator determines only the connection it will use to post the next command. For each command, the connexion id of the next command is added in the header field "next connection" of each command. Doing that, leads to the same algorithm as in the asymmetric model to process the commands on the target side: - a thread of execution pulls the cmd/data in order from the TCP windows. After pulling a cmd/data, it looks at the "next connection" field and move to the next connection to pull a new cmd/data. There is no need of extra storage out of the TCP windows and no need to re-order. In the asymmetric model the thread empties the command connection, here it follows the chain of commands. The advantage of this proposal are: - on the target, as opposed to the original symmetric model, it avoids the re-ordering process of the commands once extracted off the TCP window. - it keeps cmd/data/status on a same connexion avoiding the synchronization penalty for the READS on the initiator (described by Somesh Gupta) - it saves one TCP connection compared to the asymmetric model. Anyway any ordering implementation adds overhead, thus, as in most cases (disks) it is not required, It would be possible to deactivate it. Regards, Pierre
Home Last updated: Tue Sep 04 01:07:18 2001 6315 messages in chronological order |