Re: Avoiding deadlock in iSCSI

[Pierre Labat <pierre_labat@hp.com>]

Matt Wakeley wrote:

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

The advantage is on the target side. The target doesn't need extra storage to
re-order
commands. I mean by "extra" storage that is not allocated to the TCP windows.
In the symmetric model as described in the draft, the target needs to
- read commands/data from the TCP connexions store them in a temporary location,
- continue to do that till the "holes" between the out of order commands are
filled
- then process the commands
Hence the target needs to manage this extra space that is difficult to size
because it depends on the degree of "out-of-order" the commands
arrive. In the proposal below the target can process the command
as soon as it extracts it from the TCP window.
It seems to me that avoiding this work to the target could help it.
But i am not an expert in target, hence may be this re-ordering is not a problem
and needs only extra cheap memory?

Regards,

Pierre

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