Re: iSCSI: Abort task

[julian_satran@il.ibm.com]

Pierre,

I am not sure that I follow completely (and accurately) your line of
thought  but if you have a multiple connection session the command
numbering is meant to offer a total ordering.  Any of the scenarios you
mention can't happen unless the target decides to deliver commands to the
"SCSI layer" out of order.
And even if it does deliver command out of order (there might be good
reasons for it) it should build a "sync barrier" for those commands that
mandate ordering.  This type of problem exist also in FCP (on a single
connection!) and I assume that the thinking there is to use the per LU
command ordering to avoid task management PDUs  (like clear a queue)
arriving before the commands they are referring to.

I hope this clarifies the issue.

Julo

Pierre Labat <pierre_labat@hp.com> on 09/01/2001 11:39:53

Please respond to Pierre Labat <pierre_labat@hp.com>

To:   ips@ece.cmu.edu
cc:
Subject:  iSCSI: Abort task




Julian,


It seems that we need to specify more the "Abort task" to avoid
some problems. Below are 3 points we should add in the spec:


1) An "Abort task" must be sent on the TCP connection that was used
   to send the command. This does not apply if the connection used
   for the command has been "logged out". In this case of course, the
   "Abort task" can be send on another  connection and it will not hurt.

  It is to avoid that a command that was delayed in the network, finally
make it
  after the "Abort task" as been processed.

2) When the initiator receives the "Abort task" response, if the
  ExpCmdRN returned in the "Abort task" response is
   <= CmdRN of the aborted task, the initiator must re-use this
   CmdRN for another task (any).

3) The target when receiving an "Abort task"  for a task whose the
     CmdRN (retreived from the initiator task tag) is >= ExpCmdRN
     must not bridge this CmdRN. I mean by bridge: allow ExpCmdRN to
     pass the CmdRN value of the aborted task. It will be up to the
initiator
     to send another command with the same CmdRN in order to allow
     the target to move ExpCmdRN over the CmdRN value of the
     aborted task.



"3)"  Is to prevent to following scenario:

Two TCP connections 1 and 2 in the session
ExpCmdRN = 2

a) the command with CmdRN = 3 is sent over  connection1

b) the command with CmdRN = 4 is sent over connection 2

c) the command CmdRN = 4 reaches the target

d) the initiator aborts the command 4 and bridges CmdRN=4

e) the target receives the command 3, and as CmdRN=4 is bridged,
advances ExpCmdRN to 5

f) the initiator sends another command (not related with the aborted
one) with CmdRN=4

g) the target drops this command because CmdRN is less than ExpCmdRN.



"2)" needs to exist because if the initiator doesn't re-use the CmdRN
the target
will deadlock because ExpCmdRN will be stuck behind the CmdRN of
the aborted command.



An alternative to the points 2) and 3) would be the initiator not
re-using
the CmdRN of the aborted commands. But this requires the target to
bridge
all the CmdRNs of the Aborted tasks (need extra states) and anyway there

is a scenario where it doesn't work. Hence this is a bad alternative.

Scenario where it doesn't work:

Session with 2 connections 1 and 2.
ExpCmdRN=1

a) Command with CmdRN=4 is sent over connection1

b) Connection 1 drops and the command 4 will never make it to the
target.

c) A logout for the connection 1 is sent over connection 2

d) The initiator sends an "Abort task" (for the task CmdRN=4) over
    the connection 2

e) The target, from the referenced initiator task tag cannot find the
     CmdRN of the aborted task because the initiator task tag
corresponds
     to nothing because the command has never been received.
    Hence the target is not able to bridge CmdRN=4

f) As the initiator does not re-use CmdRN=4 the target will deadlock
    when ExpCmdRN will be 4.


Regards,

Pierre