RE: iSCSI: RefCmdSN != CmdSN

[Eddy Quicksall <Eddy_Quicksall@ivivity.com>]

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