Re: iSCSI: Abort task

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

Julian,

Exchange state should not go beyond each CDB in the linked command. The
only requirement is that the same Initiator Task Tag be used for all the
CDBs in the linked command [and thereby, the task tag cannot be re-used
for another task, until the linked command is complete].

So, I don't think this is an issue for Linked Commands.

However, the Abort Task/Task_Set, Clear Task Set, 
LUN Reset and Target Reset :

a) Involve device drivers co-ordinating individual I/O aborts across 
different NIC instances to invalidate the SCSI H/W Assist structures that 
are in use by each NIC for the I/Os being aborted on their connections.

b) Could cause out-of-order issues with commands arriving after completion
of the task management command. While it is true that 
command ordering should handle any out-of-order issues when
notifying the SCSI ULP at the target end, it may not be sufficient 
for the following reasons :

o	The Task Management Commands may be sent with a CmdRN of 0
	(immediate delivery).

o	The Abort process at the target end would typically involve
	invalidation of SCSI Hardware Assist structures at the iSCSI layer 
	and this act is not subject to the ordering enforced by CmdRN.

BTW, SCSI-FCP implementations are not likely to be prone to this
out-of-ordering syndrome, because, in a private loop, order is maintained
and all fabric initiator implementations are required to
request in-order delivery in their FLOGI with the fabric. 
(FC-FLA Table 3).

Enforcing "Connection Allegiance" can solve the out-of-ordering and 
multiple network adapter connection issue for the Abort Task. 

For Abort Task Set, Clear Task Set, LUN Reset and Target Reset, 
out-of-ordering and dependence across multiple NIC instances 
seem to be issues.

Regards,
Santosh



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


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