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

["Julian Satran" <Julian_Satran@il.ibm.com>]

----- Forwarded by Julian Satran/Haifa/IBM on 10-11-01 17:28 -----


Julian Satran
10-11-01 17:26


        To:     <somesh_gupta@silverbacksystems.com>
        cc: 
        From:   Julian Satran/Haifa/IBM@IBMIL
        Subject:        RE: iSCSI: Clarification (again) for Task Management Commands
 





Read 9.4 for one implementation - Julo




"Somesh Gupta" <somesh_gupta@silverbacksystems.com>
Sent by: owner-ips@ece.cmu.edu
10-11-01 05:26
Please respond to somesh_gupta

 
        To:     <Black_David@emc.com>, <ips@ece.cmu.edu>
        cc: 
        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
> > 
>