RE: iSCSI: Clarification (again) for Task Management Commands

[Black_David@emc.com]

Somesh,

What do you have in mind?  In practice, completion of any
command sent after the aborted "zombies" serves as a "flushing"
event for the connection on which that command is sent; if
the Initiator is reasonably busy, I think the "flushing"
occurs fairly quickly.

An initiator can also selectively fall back to the FCP-like
technique of explicitly issuing a task abort for the "zombie"
it wants to recover on the appropriate connection.

Thanks,
--David

> -----Original Message-----
> From: Somesh Gupta [mailto:somesh_gupta@silverbacksystems.com]
> Sent: Friday, November 09, 2001 10:26 PM
> To: Black_David@emc.com; ips@ece.cmu.edu
> Subject: RE: iSCSI: Clarification (again) for Task Management Commands
> 
> 
> David,
> 
> In iSCSI the multiple connection/session construct 
> adds significant complexity in determining whether
> a response for a command (on a different connection
> than the one on which the task management command
> was sent) impacted by the task management command will
> be received or not - and when?
> 
> On a single connection, or similar links, when the
> response for the task management command is
> received (or after a fixed additional time), no
> responses will be received for the commands aborted
> by the task management command.
> 
> However, with multiple connections there is no
> such "flushing" event on connections other than the
> one on which the task management command was sent.
> 
> I would hope that the protocol would address this
> situation - the current response seems to be be to
> put the task tag and some associated resources in
> a zombie state for an unspecified amount of time.
> 
> Somesh
> 
> 
> > -----Original Message-----
> > From: Black_David@emc.com [mailto:Black_David@emc.com]
> > Sent: Friday, November 09, 2001 6:53 PM
> > To: somesh_gupta@silverbacksystems.com; ips@ece.cmu.edu
> > Subject: RE: iSCSI: Clarification (again) for Task 
> Management Commands
> > 
> > 
> > Somesh,
> > 
> > The language in question reflects fairly direct requirements
> > language to be found in SAM-2's description of SCSI Task Management.
> > FCP goes to serious lengths with FC sequence aborts to make sure
> > this behaves as required.
> > 
> > For iSCSI, if responses to the aborted commands show up 
> unexpectedly,
> > they have to be discarded.  How the Initiator keeps track of that
> > is the Initiator's problem - keeping track of the CmdSN of the
> > Abort Task Set may be useful.
> > 
> > --David
> > ---------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 42 South St., Hopkinton, MA  01748
> > +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> > black_david@emc.com       Mobile: +1 (978) 394-7754
> > ---------------------------------------------------
> > 
> > > -----Original Message-----
> > > From: Somesh Gupta [mailto:somesh_gupta@silverbacksystems.com]
> > > Sent: Friday, November 09, 2001 4:55 PM
> > > To: IPS
> > > Subject: iSCSI: Clarification (again) for Task Management Commands
> > > 
> > > 
> > > Resend to add iSCSI tag. Sorry for missing it.
> > > 
> > > On page 67 of the 8-92.txt draft (section 3.5.1), it
> > > says
> > > 
> > > "For all the tasks covered by the task 
> > > management response (i.e., with CmdSN not higher than the task 
> > > management command CmdSN), additional responses MUST NOT 
> be delivered 
> > > to the SCSI layer after the task management response."
> > > 
> > > If there is a multiple connection session,
> > > a status for a command impacted by the task
> > > management command (say ABORT TASK SET) could
> > > be stuck in the pipe on one connection, while
> > > the ABORT TASK SET completes on another
> > > connection.
> > > 
> > > How does the initiator iSCSI enforce the rule above?
> > > Seems to be the equivalent of sending the impacted
> > > commands on other connections in a zombie state,
> > > and not having a very good idea of how to get out.
> > > 
> > > Similarly Section 9.4 provides additional rules,
> > > but seems to leave a hole open with regards to
> > > status already in flight on other connections.
> > > 
> > > Any clarifications would be appreciated.
> > > 
> > > Somesh
> > > 
> > 
>