Subject: RE: iSCSI:Clear Task Set

From: [email-masked]
Date: Sat, 1 Dec 2001 20:02:35 -0500

On rereading the original thread, I screwed up ...

> - I think John started this thread with a confused notion.

That's wrong and I apologize.  John's initial post was
about using LU rather than LUN, which is correct.  The
thread subsequently drifted in the direction of trying
to have iSCSI do some sort of coordination of Clear Task
Set across Initiators.  As I hope is clear from below,
those sort of effects are in SCSI's domain and not completely
predictable.

Thanks/Sorry,
--David 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Saturday, December 01, 2001 4:50 PM
> To: [email-masked]; [email-masked]
> Subject: RE: iSCSI:Clear Task Set
> 
> 
> A few points of advice on this issue:
> - Clear Task Set needs to be in the iSCSI protocol.  It can
> 	be OPTIONAL to implement, but failing to specify it will
> 	cause issues with T10 down the road.
> - I think John started this thread with a confused notion.
> 	SCSI does not require any ordering of delivery across
> 	multiple nexii (nexuses).  All the stuff in 9.4 applies
> 	only to the iSCSI session on which the Clear Task Set
> 	arrives, and exists because we are trying to:
> 	- Have our cake: Process Clear Task Set immediately
> 		without waiting for any prior (according to CmdSN)
> 		in-flight commands to arrive.
> 	- And eat it too: Respect SAM-2's ordering requirements
> 		for Task Management commands.  As noted above,
> 		these requirements only apply to a single iSCSI
> 		session (SCSI IT nexus).
> - Please recall a number of prior comments from SCSI experts
> 	on this list about the effects of SCSI task management
> 	commands (e.g., Clear Task Set) not being entirely
> 	predictable.  If there are commands in flight/pending
> 	on one nexus and a Clear Task Set is issued to the same LU
> 	on another nexus, there are a number of possible outcomes
> 	in terms of which commands on the first nexus are aborted.
> 
> Thanks,
> --David
> 
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> [email-masked]       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
> 
> 
> > -----Original Message-----
> > From: Julian Satran [mailto:[email-masked]]
> > Sent: Saturday, December 01, 2001 11:18 AM
> > To: [email-masked]
> > Subject: Re: iSCSI:Clear Task Set
> > 
> > 
> > Mallikarjun,
> > 
> > I am afraid that is not entirely possible as it may affect 
> other iSCSI
> > barier sets (that is SCSI semantics).
> > Clear task-set is a SCSI command that has clear delivery 
> > underpinnings and
> > (as some others) does not offer an easy "layering" way 
> out).  We might
> > either drop it (implementation is not mandatory) or implement 
> > it with all
> > effects on other initiators.
> > Please do not forget that implementers choosing a common 
> > queue technique
> > know what to expect - and they expect a full clear.
> > We may want to take this off-line for a while.
> > 
> > Julo
> > 
> > 
> > 
> >                                                               
> >                                                             
>           
> >                     "Mallikarjun                              
> >                                                             
>           
> >                     C."                  To:     ips 
> > <[email-masked]>                                             
> >                  
> >                     <[email-masked]       cc:                  
> >                                                             
>           
> >                     om>                  Subject:     Re: 
> > iSCSI:Clear Task Set                                          
> >             
> >                     Sent by:                                  
> >                                                             
>           
> >                     owner-ips@ece.                            
> >                                                             
>           
> >                     cmu.edu                                   
> >                                                             
>           
> >                                                               
> >                                                             
>           
> >                                                               
> >                                                             
>           
> >                     12/01/2001                                
> >                                                             
>           
> >                     02:28 AM                                  
> >                                                             
>           
> >                     Please respond                            
> >                                                             
>           
> >                     to cbm                                    
> >                                                             
>           
> >                                                               
> >                                                             
>           
> >                                                               
> >                                                             
>           
> > 
> > 
> > 
> > Julian,
> > 
> > I tend to agree with John on this one.
> > 
> > Passing the 'clear task set' onto target SCSI layer once
> > the current session is dealt with is the right choice.  That
> > avoids iSCSI having to say anything on the relative order
> > across sessions, and also addresses the issue John raised -
> > that of differing LUN mappings for the same LU.
> > 
> > At a minimum, the second sentence in the current wording
> > 
> > "All tasks associated with the specified LUN and initiator.
> >  For all other initiators all tasks at LUN with no regard
> >  to order."
> > 
> > should be dropped since it implies that 'clear task set' affects
> > all other initiators.  In fact, this determination can not be made
> > until the TST bit is checked in the SCSI control mode page - which
> > is completely in the SCSI realm.  That of course requires the task
> > management function to be propagated up.
> > 
> > Regards.
> > --
> > Mallikarjun
> > 
> > 
> > Mallikarjun Chadalapaka
> > Networked Storage Architecture
> > Network Storage Solutions Organization
> > MS 5668 Hewlett-Packard, Roseville.
> > [email-masked]
> > 
> > Julian Satran wrote:
> > >
> > > John,
> > >
> > > That looks more like in  T10 territory.
> > > T10 defines differently Abort Task Set and Clear Task Set.
> > > We could either:
> > >
> > > decide not to implement clear task set (T10 allows that but 
> > "per target"
> > > not "per transport")
> > > enable clear task set - in which case we have to say 
> > something about the
> > > relative order of the task management request with regard 
> > to the  task
> > > comming from other initiators - and that is what I 
> > attempted to say in
> > 9.4
> > >
> > > Julo
> > >
> > > John Hufferd/San Jose/IBM@IBMUS
> > > Sent by: [email-masked]
> > > 23-11-01 23:30
> > >
> > >
> > >         To:     Julian Satran/Haifa/IBM@IBMIL
> > >         cc:     [email-masked]
> > >         Subject:        Re: iSCSI:Clear Task Set
> > >
> > >
> > >
> > > Julian, and list,
> > > The question now becomes, if we have all that carefully 
> thought out
> > > processing that is defined in 9.4 in how to handle the other
> > > Tasks/Commands
> > > that are "In Flight", and not yet given to SCSI, how does 
> > that apply to
> > > the
> > > other Sessions with other initiators?
> > >
> > > That is, at the iSCSI Target layer we do not have the LU 
> > Number to LU
> > > mapping on any Session with any Initiator, so how do we 
> > cause the careful
> > > processing, which is defined in 9.4, to occur on the other 
> > sessions that
> > > may have and association to the subject LU? Especially 
> > since all we know
> > > is
> > > a LU Number on the Clearing Session.
> > >
> > > Perhaps we do not care about the 9.4 processing on the 
> > other Session and
> > > Other Initiators and just let SCSI layer do its thing, and 
> > at the iSCSI
> > > layer we pay no attention to the other Sessions.  Do you 
> > think this is
> > > correct?
> > >
> > > .
> > > .
> > > .
> > > John L. Hufferd
> > > Senior Technical Staff Member (STSM)
> > > IBM/SSG San Jose Ca
> > > Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> > > Home Office (408) 997-6136, Cell: (408) 499-9702
> > > Internet address: [email-masked]
> > >
> > > Julian Satran/Haifa/IBM@[email-masked] on 11/23/2001 
> 07:56:36 AM
> > >
> > > Sent by:  [email-masked]
> > >
> > > To:   [email-masked]
> > > cc:
> > > Subject:  Re: iSCSI:Clear Task Set
> > >
> > > John,
> > >
> > > The LUN is just a mistake there - in all three instances it 
> > should be LU.
> > > The definitions are in accordance with SAM . There are two task
> > management
> > > modes - tasks sets-per-initiator at each LU or common for 
> > all initiators.
> > > The mode is a SCSI issue controlled by a field in the 
> > Control-Mode page.
> > > Clear task set MAY clear all the tasks in the task set - 
> > even if common
> > to
> > > all initiators if that is the way the task set is managed. 
> > That is also
> > > the difference between clear-task-set and abort task set.
> > >
> > > Julo
> > >
> > > John Hufferd@IBMUS
> > > 23-11-01 11:29
> > >
> > >         To:     Julian Satran/Haifa/IBM@IBMIL@IBMDE
> > >         cc:     [email-masked]
> > >         From:   John Hufferd/San Jose/IBM@IBMUS
> > >         Subject:        iSCSI:Clear Task Set
> > >
> > > Julian, and List  (using v 0.9)
> > > In point 9.4, just before 9.5  the Table entry associated 
> > with Clear Task
> > > Set applies to:
> > >
> > > "All tasks associated with the specified LUN and initiator. 
> > For all other
> > > initiators all tasks at LUN with no regard to order."
> > >
> > > Perhaps we mean LU here, but I know that the iSCSI layer 
> > does not have
> > > information about LU, only about the LU Number (LUN) in the 
> > command.  We
> > > can not tell, at the iSCSI layer, if the  LU represented  
> > by a LUN on
> > > Session 1, has any relationship to any LUN on any other session.
> > >
> > > This is because each initiator may have their own 
> numbering for LUs.
> > > Therefore, do we just pass the Clear Task Set to the SCSI 
> > layer and hope
> > > for the best, or does the iSCSI layer also suppose to apply 
> > the Clear
> > Task
> > > Set to all the sessions that it has coming into the iSCSI 
> > (SCSI) Target
> > > Port?  If the latter, again how will that work when the 
> > iSCSI layer has
> > no
> > > idea what LU an Initiator's LUN will map to?
> > > .
> > > .
> > > .
> > > John L. Hufferd
> > > Senior Technical Staff Member (STSM)
> > > IBM/SSG San Jose Ca
> > > Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> > > Home Office (408) 997-6136, Cell: (408) 499-9702
> > > Internet address: [email-masked]
> > 
> > 
> > 
> > 
>

---

From: "Mallikarjun C." <[email-masked]>
Date: Sun, 2 Dec 2001 15:46:54 -0800

> those sort of effects are in SCSI's domain and not completely

Exactly.  That's the reason I suggested that iSCSI should not comment
on ordering or lack thereof  for other sessions, and also suggested that
we note that the said task management function be propagated upto SCSI
always.

Julian may have other reasons - I will check with him as he suggested.
--
Mallikarjun

Mallikarjun Chadalapaka
Hewlett-Packard MS 5668 
Roseville CA 95747