Re: iSCSI: Abort task

[Santosh Rao <santoshr@cup.hp.com>]

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