Re: iSCSI: Abort task

[julian_satran@il.ibm.com]

Santosh,

That is an interesting point. Not so much for abort task but for linked
commands.
For abort task we could point out that it might we advisable to keep
connection allegiance but
we want a way to abort tasks beyond the connection (as your argument holds
for clear task set too).
On the other hand we did not require connection allegiance beyond
individual commands in
a linked command set. Do your exchange state go beyond individual commands
in a linked set?

Julo



Santosh Rao <santoshr@cup.hp.com> on 15/01/2001 09:41:46

Please respond to Santosh Rao <santoshr@cup.hp.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   ips@ece.cmu.edu
Subject:  Re: iSCSI: Abort task




Julian,

Another reason for enforcing "connection allegiance" of Abort Task and its
associated task :

In the case of multi-connection sessions, each connection can be using a
different NIC. The SCSI command state information is maintained in SCSI
hardware assists (SCSI Exchange State Tables) on the adapter and such
structures need to be invalidated while aborting an I/O.

Handling the Abort Task and the task on different connections implies
having to then share state information across NIC instances, something
that iSCSI has been trying to avoid.

Regards,
Santosh


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


--
#################################
Santosh Rao
Software Design Engineer,
HP, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
#################################