Re: Avoiding deadlock in iSCSI

[Pierre Labat <pierre_labat@hp.com>]

julian_satran@il.ibm.com wrote:
Julo,

> Pierre,
>
> Sorry (and excuses to Kalman) - I misread you.
> I think that the idea behind the symmetric model is to stripe the traffic
> command-by-command.
> You could hardly ask that an initiator make decisions  based only on the
> past (as your recommendation would imply) and without examining some of the
> command parameters.

It is a "recent" past, for one command. That means that the N+1 command is
posted on a connexion based on a state of the connexions established after the

posting of the command number N. Hence the context of the connections
regarding the cmd/data enqueued has not changed a lot.

You can examine the command parameters to maintain  a "state" of each
connexion
(how much data/command queued). But as you say even if the initiator
knows the "state" of each connexion, it must take a decision only based on
that
and not knowing the nature of the next command.

>
>
> The what if between this command and the next the connection goes away?

You get the same kind of problem when the command connexion of the asymmetric
model goes away. You need to restart the commands from the last command
completed in order.
On this point i think there is no difference between this model and the
asymmetric
one.

>
>
> And on the target - with your scheme you can do only one command read at a
> time (no parallel operation of the pipes) admittedly not that disastrous.
>

You can do the same thing you do with the asymmetric model. You can read ahead
some
commands following the chain and processing them in parallel. It is the same
thing as you can do dequeuing several READS from the command connection and
processing them in parallel.
In fact the chain of command materializes in an other way the queue of
commands you
have in the command connection tcp window of the asymmetric model.
Hence on this point i think there is no difference.

>
> How about chaining back (each command indicates where the previous came
> from)?
>
> Will it work better? (probably not - all relative schemes are bad when they
> loose sync.)

Well, the command connexion materializes too, a relative scheme. The relation
is the order of the commands in the TCP window of this connexion.
If you loose this connexion you are in a bad shape too.

>
> Can you try? (I am on the road and in a hurry - that's why I missed your
> context).

I'll try.

Regards,

Pierre

>
>
> We will probably polish Kalman's proposal to ease en-of-data and status
> sync - but the essence
> is that the parties know ahead of time where the data will be coming.
>
> Regards,
> Julo
>
>
> >
> > Pierre Labat <pierre_labat@hp.com> on 13/09/2000 11:48:58
> >
> > Please respond to Pierre Labat <pierre_labat@hp.com>
> >
> > To:   ips@ece.cmu.edu
> > cc:    (bcc: Julian Satran/Haifa/IBM)
> > Subject:  RE: Avoiding deadlock in iSCSI
> >
> > >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