Re: Avoiding deadlock in iSCSI

["Matt Wakeley" <matt_wakeley@agilent.com>]

Pierre

All you have done is to suggest an alternative method of "re-ordering"
commands that come down different tcp connections.  I don't see how it has any
advantages over the existing symmetric model.

-Matt

Pierre Labat wrote:

> From 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