Re: iSCSI : Bridging missing CmdSNs and Abort I/O Error recovery

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

All,

I did'nt hear back any response on this and am raising the issue again.
An Abort Task MUST be sent on the same connection as the command unless
that connection was logged out due to connection recovery.

If the connection was logged out for closing the connection (1), 
closing the session (0), or removes the connection at target's request
(3), an Abort Task is meaningless since all pending tasks are cleaned up
at the target by this action.

In all other cases, an Abort Task cannot be used to perform a clean-up
of the command and ensure deterministic release of resources, since the
Abort Task response can arrive ahead of other in-flight PDUs from target
to initiator on another connection.

Comments ?

- Santosh

ps : While on the subject of connection allegiance as defined in Section
1.2.5, this definition must be extended to specify that the response for
ALL iSCSI command PDUs MUST be sent on the same connection as the
command. 




Santosh Rao wrote:
> 
> Julian,
> 
> I have re-read your previous answer and I may be missing something, but,
> I don't see how it addresses my concern (?).
> 
> Per your mail :
> "To abort safely a task for which the task abort answer is "Command Not
> Received Yet" the initiator must issue another abort command on the same
> connection as the original command unless this connection was logged out
> in which case it may send it on any connection."
> 
> I'm pointing out that the above may not be sufficient since the issue
> spans beyond that. If the target HAD received the command by the time it
> received the task mgmt command on another connection, it would not
> respond with "Command not received yet". In this case, the initiator
> would not be required to re-send the Abort Task on the same connection
> as the original command.
> 
> In such a scenario, if there were PDUs in-flight from target to
> initiator on the original connection, these could arrive after the task
> mgmt response [which is on the 2nd connection]. Such an Abort Task
> cleanup does not reliably allow the initiator to free its task tag and
> other resources, since PDUs for that task continue to arrive on the
> original connection after the initiator has completed task clean-up
> using Abort Task & released the task resources.
> 
> - Santosh
> 
> julian_satran@il.ibm.com wrote:
> >
> > please reread carefully my previous answer. Julo
> >
> > Santosh Rao <santoshr@cup.hp.com> on 09-05-2001 19:37:41
> >
> > Please respond to Santosh Rao <santoshr@cup.hp.com>
> >
> > To:   IPS Reflector <ips@ece.cmu.edu>
> > cc:
> > Subject:  Re: iSCSI : Bridging missing CmdSNs and Abort I/O Error recovery
> >
> > > julian_satran@il.ibm.com wrote:
> >
> > > > > We could add the RefCmdSN and it may help plug-in the hole but unless
> > the
> > > > > Abort is ussued on the same connection as the original command we
> > can't
> > > > be
> > > > > sure that the old-one will not pop-up (as we enable ExpCmdSN to move
> > on
> > > > we
> > > > > don't have even the 2**31-1 protection bracket :-)). Thus sending in
> > > > > another nop/abort on the same connection is still required.
> > > > >
> > > > > To simplify the whole process I will:
> > > > >
> > > > >  a - add RefCmdSN to the Task Management
> > > > >  b - add a command not received yet to the answers
> > > > >
> > > > >  c - add a part to 7 reading:
> > > > >
> > > > > 1.1  How to Abort Safely a Command that Was Not Received
> > > > >
> > > > >    To abort safely a task for which the task abort answer is "Command
> > Not
> > > > >    Received Yet" the initiator must issue another abort command on
> > the
> > > > same
> > > > >    connection as the original command unless this connection was
> > logged
> > > > out
> > > > >    in which case it may send it on any connection.
> >
> > Julian,
> >
> > The above may not be sufficient, since a requirement for the Abort Task
> > completion is that both the initiator & target can safely re-use their
> > task tags and other resources following completion of the Abort Task. If
> > the Abort Task is sent on another connection than the connection used
> > for the original command [& that connection has not been logged out],
> > then, there may be some in-flight PDUs from the target to the initiator
> > for that command on the connection.
> >
> > Sending an Abort Task on another connection may cause the initiator to
> > receive the Abort Task response indicating success on the other
> > connection which then results in initiator freeing up its task tag and
> > other resources used for that command. Thereafter, the stale PDUs on the
> > original connection can show up at the initiator, causing problems.
> >
> > I would suggest that Abort Task be always sent on the same connection as
> > the command, unless the connection used for that command has been logged
> > out. Not doing so implies the initiator cannot safely re-use its task
> > tag and other resources that were tied up for that I/O.
> >
> > Regards,
> > Santosh
> >  - santoshr.vcf
begin:vcard 
n:Rao;Santosh 
tel;work:408-447-3751
x-mozilla-html:FALSE
org:Hewlett Packard, Cupertino.;SISL
adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
version:2.1
email;internet:santoshr@cup.hp.com
title:Software Design Engineer
x-mozilla-cpt:;21088
fn:Santosh Rao
end:vcard