Re: iSCSI: RefCmdSN != CmdSN

["Mallikarjun C." <cbm@rose.hp.com>]

I would actually tweak it a little further - dropping "yet"
(since it wouldn't ever be received), adding more text to 
deal with a received and concluded task (RefCmdSN out of 
the valid CmdSN window), and also dropping the last sentence 
which is really describing the options (I don't mind adding
it in either...).

Section 9.5.4
 For the ABORT TASK function, initiators MUST always set this to the
 CmdSN of the task identified by the Initiator Task Tag field.  Targets
 must use this field as described in section 9.6.1 when the task 
 identified by the ITT field is not with the target. 


-- 
Mallikarjun 


Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
cbm@rose.hp.com


Eddy Quicksall wrote:
> 
> Based on that, may I suggest this wording?
> 
> Section 9.5.4
> For the ABORT TASK function, initiators MUST always set this to the
> CmdSN of the task identified by the Initiator Task Tag field.  Targets
> use this field when the command has not yet arrived. Otherwise the
> target has the option of using either RefCmdSN or Initiator Task Tag
> to locate the command.
> 
> That way, you are not mandating the implementation.
> 
> --snip for backward reference--
> >Targets however
> >must consider the field valid only when the task indicated by the Initiator
> >Task Tag field does not exist.
> 
> Eddy
> 
> -----Original Message-----
> From: Mallikarjun C. [mailto:cbm@rose.hp.com]
> Sent: Friday, March 01, 2002 4:09 PM
> To: ips@ece. cmu. edu (E-mail)
> Subject: Re: iSCSI: RefCmdSN != CmdSN
> 
> > If the initiator must make them consistent, why does the spec have to
> > specify how the target uses them?
> 
> You are correct, but it is only partially related to what I said -
> 
> " I believe we should have some text that specifies the target
>   is required to look at RefCmdSN."
> 
> There is one case where the target must use RefCmdSN in one
> way - to act on a command that it had not received, by plugging
> the CmdSN slot.  This must be clear in the draft to prevent
> incorrect target implementations.
> 
> You are discussing the other cases where the target may use
> RefCmdSN and suggesting relaxing the wording I proposed -
> that's fine with me.  I was only pointing out that it's not all
> implementation dependent.
> --
> Mallikarjun
> 
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> Hewlett-Packard MS 5668
> Roseville CA 95747
> 
> ----- Original Message -----
> From: "Eddy Quicksall" <Eddy_Quicksall@ivivity.com>
> To: "Mallikarjun C." <cbm@rose.hp.com>
> Cc: "ips@ece. cmu. edu (E-mail)" <ips@ece.cmu.edu>
> Sent: Friday, March 01, 2002 12:29 PM
> Subject: RE: iSCSI: RefCmdSN != CmdSN
> 
> > If the initiator must make them consistent, why does the spec have to
> > specify how the target uses them?
> >
> > For example, the ITT could exist in one of the "out of sequence buckets".
> > Those buckets are indexed by the CmdSN (RefCmdSN in this case).
> >
> > Now, in this case the ITT does exist but it would be silly for the target
> to
> > search the buckets for the ITT when it could just do a direct reference
> > using the RefCmdSN. That is why it is an implementation issue. (note, to
> the
> > target the ITT is not a pointer).
> >
> > Eddy
> >
> > -----Original Message-----
> > From: Mallikarjun C. [mailto:cbm@rose.hp.com]
> > Sent: Friday, March 01, 2002 1:43 PM
> > To: Eddy Quicksall
> > Cc: ips@ece. cmu. edu (E-mail)
> > Subject: Re: iSCSI: RefCmdSN != CmdSN
> >
> >
> > It isn't quite an implementation issue.  The spec *requires*
> > the target to look at RefCmdSN - and that's only when the
> > ITT doesn't point to a valid task.
> >
> > I believe we should have some text that specifies the target
> > is required to look at RefCmdSN.
> > --
> > Mallikarjun
> >
> > Mallikarjun Chadalapaka
> > Networked Storage Architecture
> > Network Storage Solutions Organization
> > Hewlett-Packard MS 5668
> > Roseville CA 95747
> >
> >
> > ----- Original Message -----
> > From: "Eddy Quicksall" <Eddy_Quicksall@ivivity.com>
> > To: "Mallikarjun C." <cbm@rose.hp.com>
> > Cc: "ips@ece. cmu. edu (E-mail)" <ips@ece.cmu.edu>
> > Sent: Friday, March 01, 2002 6:22 AM
> > Subject: RE: iSCSI: RefCmdSN != CmdSN
> >
> >
> > > Yes, but I don't think the statement "Targets however must consider ..."
> > is
> > > necessary because the initiator must always make them consistent and it
> is
> > a
> > > target implementation issue as to which it actually uses.
> > >
> > >
> > > Eddy
> > >
> > > -----Original Message-----
> > > From: Mallikarjun C. [mailto:cbm@rose.hp.com]
> > > Sent: Thursday, February 28, 2002 8:47 PM
> > > To: ips@ece. cmu. edu (E-mail)
> > > Subject: Re: iSCSI: RefCmdSN != CmdSN
> > >
> > >
> > > Eddy,
> > >
> > > I agree that targets don't have to check both always, only when it
> > > is needed.
> > >
> > > The intended role of RefCmdSN is to help identify the right command
> > > when the command to be aborted had not arrived - the command
> > > could be lost due to digest errors or as part of connection failure.
> > > So I think the quoted text should be rephrased to:
> > >
> > > Section 9.5.4
> > > For the ABORT TASK function, initiators MUST always set this to the
> > > CmdSN of the task identified by the Initiator Task Tag field.  Targets
> > > however
> > > must consider the field valid only when the task indicated by the
> > Initiator
> > > Task Tag field does not exist.
> > >
> > > Section 9.6.1
> > > For the ABORT TASK function,
> > >     a) if the ITT identifies a valid task leading to a successful
> > > termination,
> > >         targets must return the "Function complete" response.
> > >     b)if the ITT does not identify an existing task but if the CmdSN
> > > indicated
> > >        by the RefCmdSN field in the task management function request is
> > > within
> > >        the valid CmdSN window, targets must consider the CmdSN received
> > >        and return the "Function complete" response.
> > >    c) if the ITT does not identify an existing task and if the CmdSN
> > > indicated
> > >        by the RefCmdSN field in the task management function request is
> > > outside
> > >        the valid CmdSN window, targets must return the "Task does not
> > exist"
> > > response.
> > >
> > > Comments?
> > > --
> > > Mallikarjun
> > >
> > > Mallikarjun Chadalapaka
> > > Networked Storage Architecture
> > > Network Storage Solutions Organization
> > > Hewlett-Packard MS 5668
> > > Roseville CA 95747
> > >
> > > ----- Original Message -----
> > > From: "Eddy Quicksall" <Eddy_Quicksall@ivivity.com>
> > > To: "ips@ece. cmu. edu (E-mail)" <ips@ece.cmu.edu>
> > > Sent: Thursday, February 28, 2002 4:46 PM
> > > Subject: iSCSI: RefCmdSN != CmdSN
> > >
> > >
> > > > Is there a reason that this check is mandated? Is there a case where
> > this
> > > > can happen with bug free code?
> > > >
> > > >  If RefCmdSN does not match the CmdSN of the command to be aborted at
> > the
> > > >  target, the abort action MUST NOT be performed and the response MUST
> > > >  be 'function rejected'.
> > > >
> > > >
> > > > Eddy_Quicksall@iVivity.com
> > > >
> > >
> >