RE: iSCSI: RefCmdSN != CmdSN

[Eddy Quicksall <Eddy_Quicksall@ivivity.com>]

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
> > >
> > 
>