Mallikarjun C. | 1 Jun 01:23 2005
Picon

Re: ABORT TASK vs ABORT TASK SET

Responding to my own comment (since I seem to have done such a fine job 
of "aborting" this email thread).....

> I think it'd be a good idea to elaborate on LU Reset, and the two
> flavors of Target Reset in a formal IETF doc.

I am concerned that the current lack of detailed specification would
allow targets that might even cause silent data corruptions to qualify 
as RFC 3720-compliant.

Here are what I believe to be semantics applicable to all TMF requests
that can potentially terminate multiple tasks.  I do not know the IETF 
process well enough here, but I suggest that we consider this text 
replacing the existing section 10.6.2 in RFC 3720 - so the new text can 
cover all the TMFs that can impact multiple tasks.  This is basically a 
superset of the current 10.6.2 semantics.

Comments are welcome.

Mallikarjun

-----------------------------------------------------------------------

10.6.2.  Task Management Actions on Requests Affecting Multiple Tasks

The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, 
TARGET WARM RESET, and TARGET COLD RESET Task Management function 
requests consists of the following sequence of actions in the
specified order on each of the entities.

(Continue reading)

Ming Zhang | 1 Jun 14:48 2005
Picon

Re: Perfect Hashing for All 23 iSCSI Text Keys

any particular reason for hashing in a space with 23 value?

ming

On Sun, 2005-05-29 at 01:10 -0700, Faraz Ahmed wrote:
> Hi all;
>       I dont know whether this should be discussed here. As part of
> implementing a iSCSI target, we often need to search for a particular Text
> key. Here i have discovered a hashing fucntion which perfectly hashes all
> the 23 iSCSI text key.
>      The Bernsteins Hash Function wiht the MAGIC value of 34043539 hashes
> all the keys perfectly.
> 
> 
> 
> #define FARAZ_HASH_VAL 34043539
> #define PR_COL  0
> #define IDX_COL 1
> char __key_hash[MAX_KEYS][2];
> 
> 
> 
> /*
>  * Berstein Hash Fucntion for strings. Hashes all the keys uniquely
>  */
> inline int __djb2_hash(char *str_orig)
> {
> unsigned long hash = FARAZ_HASH_VAL;
> char *str = str_orig;
> int c;
(Continue reading)

Faraz Ahmed | 1 Jun 16:11 2005

Re: [linux-iscsi-devel] Re: Perfect Hashing for All 23 iSCSI Text Keys

Hi Ming;
 Its just a finding i thought that should be shared. Any ways the
optimization may minuscule, since the space being small. But I think its
better than

if(!strcmp()) elseuif (!strcmp()) my first implementation
the lexical sort/search the second one

Anyways is there some very easy, very obvious way to do this search, which
is better than the hash thing in terms of time. Do let me know. May be i
have just overlooked an approach. or tried to optimize something that is in
the end going to optimize nothing in the large scheme of work.

Regards
Faraz

----- Original Message ----- 
From: "Ming Zhang" <mingz <at> ele.uri.edu>
To: "Faraz Ahmed" <farazs <at> calsoftinc.com>
Cc: "Nicholas A. Bellinger" <nick <at> pyxtechnologies.com>; <mbrown <at> cs.uml.edu>;
<ips <at> ietf.org>; "linux-iscsi development team"
<linux-iscsi-devel <at> lists.sourceforge.net>
Sent: Wednesday, June 01, 2005 5:48 AM
Subject: [linux-iscsi-devel] Re: [Ips] Perfect Hashing for All 23 iSCSI Text
Keys

_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips
(Continue reading)

Ming Zhang | 1 Jun 15:55 2005
Picon

Re: [linux-iscsi-devel] Re: Perfect Hashing for All 23 iSCSI Text Keys

On Wed, 2005-06-01 at 07:11 -0700, Faraz Ahmed wrote:
> Hi Ming;
>  Its just a finding i thought that should be shared. Any ways the
yes, always thanks on this.

> optimization may minuscule, since the space being small. But I think its
> better than
> 
> if(!strcmp()) elseuif (!strcmp()) my first implementation
my current implementation. :P

> the lexical sort/search the second one
not even think about this. :P too complex for me.

> 
> Anyways is there some very easy, very obvious way to do this search, which
> is better than the hash thing in terms of time. Do let me know. May be i
> have just overlooked an approach. or tried to optimize something that is in
> the end going to optimize nothing in the large scheme of work.
i donot know why you need to find the text key frequently. i assumed we
only do it when setup a connection. so i prefer to spending optimization
effort on data transfer path.

ming

> 
> Regards
> Faraz
> 
> ----- Original Message ----- 
(Continue reading)

Eddy Quicksall | 2 Jun 16:29 2005
Picon
Picon

Re: ABORT TASK vs ABORT TASK SET

>       LOGICAL UNIT RESET: All outstanding tasks from all initiators for
>                       the LU identified by the LUN field in the LOGICAL
>                       UNIT RESET task management function.

Regarding "all initiators" above. In the context of 10.6.2(b), how would 
"The initiator" know anything about "all initiators"?

Eddy

----- Original Message ----- 
From: "Mallikarjun C." <cbm <at> rose.hp.com>
To: <ips <at> ietf.org>
Sent: Tuesday, May 31, 2005 7:23 PM
Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET

> Responding to my own comment (since I seem to have done such a fine job of 
> "aborting" this email thread).....
>
>> I think it'd be a good idea to elaborate on LU Reset, and the two
>> flavors of Target Reset in a formal IETF doc.
>
> I am concerned that the current lack of detailed specification would
> allow targets that might even cause silent data corruptions to qualify as 
> RFC 3720-compliant.
>
> Here are what I believe to be semantics applicable to all TMF requests
> that can potentially terminate multiple tasks.  I do not know the IETF 
> process well enough here, but I suggest that we consider this text 
> replacing the existing section 10.6.2 in RFC 3720 - so the new text can 
> cover all the TMFs that can impact multiple tasks.  This is basically a 
(Continue reading)

Eddy Quicksall | 2 Jun 16:33 2005
Picon
Picon

Re: ABORT TASK vs ABORT TASK SET

For purposes of understanding this clearly, can you please note the reason 
for each step? I'm not suggesting this note be added to the RFC but it would 
be helpful for this email thread.

Eddy

----- Original Message ----- 
From: "Mallikarjun C." <cbm <at> rose.hp.com>
To: <ips <at> ietf.org>
Sent: Tuesday, May 31, 2005 7:23 PM
Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET

> Responding to my own comment (since I seem to have done such a fine job of 
> "aborting" this email thread).....
>
>> I think it'd be a good idea to elaborate on LU Reset, and the two
>> flavors of Target Reset in a formal IETF doc.
>
> I am concerned that the current lack of detailed specification would
> allow targets that might even cause silent data corruptions to qualify as 
> RFC 3720-compliant.
>
> Here are what I believe to be semantics applicable to all TMF requests
> that can potentially terminate multiple tasks.  I do not know the IETF 
> process well enough here, but I suggest that we consider this text 
> replacing the existing section 10.6.2 in RFC 3720 - so the new text can 
> cover all the TMFs that can impact multiple tasks.  This is basically a 
> superset of the current 10.6.2 semantics.
>
> Comments are welcome.
(Continue reading)

Mallikarjun C. | 2 Jun 19:41 2005
Picon

Re: ABORT TASK vs ABORT TASK SET

As I earlier noted in my response to Gwendal, there are three main goals 
that motivated us to spec the sequence of steps.  Let me elaborate on 
those.  The three are:

1. Maintaining a single ordered command flow I_T nexus abstraction to 
the target SCSI layer even with multi-connection sessions.
      Target iSCSI processing of a TMF request must maintain the
      single flow illusion - steps c & d on the target behavior
      correspond to this goal.

2. Maintaining a single ordered response flow I_T nexus abstraction to 
the initiator SCSI layer even with multi-connection sessions.
      Target must ensure that the initiator does not see "old" task
      responses (that chronologically preceded the TMF response) after
      seeing the TMF response - step e on the target behavior corresponds
      to this goal.

3. Draining all active TTTs corresponding to affected tasks before the 
TMF is acted on.
      Targets are better off if the TTTs are deterministically retired
      before the affected tasks are terminated.  No need to worry about
      large-sized Data-out PDUs with stale TTTs arriving after the tasks
      are terminated - step b on the target behavior corresponds to this
      goal.

The proposed text caters to these same goals as did the original text - 
except it now covers all TMFs that can impact multiple tasks.

The only other notable thing in step (c) is the "plugging" part - it is 
just an optimization that says if all tasks on the I_T nexus will be 
(Continue reading)

Eddy Quicksall | 3 Jun 02:00 2005
Picon
Picon

Re: ABORT TASK vs ABORT TASK SET

Thank you. That is a very good explanation.

Two things I have always wondered:

1) Is it required (via SAM-2, SPC-2, etc) that the TMF only act on commands 
with lower CmdSN's?
2) Is it necessary to state when the TMF is passed to the SCSI layer? It 
would seem that that is an implementation issue and as long as the target 
can emulate this behavior to the initiator then it should not be specified 
in this spec.

Eddy

----- Original Message ----- 
From: "Mallikarjun C." <cbm <at> rose.hp.com>
To: <ips <at> ietf.org>
Sent: Thursday, June 02, 2005 1:41 PM
Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET

> As I earlier noted in my response to Gwendal, there are three main goals 
> that motivated us to spec the sequence of steps.  Let me elaborate on 
> those.  The three are:
>
> 1. Maintaining a single ordered command flow I_T nexus abstraction to the 
> target SCSI layer even with multi-connection sessions.
>      Target iSCSI processing of a TMF request must maintain the
>      single flow illusion - steps c & d on the target behavior
>      correspond to this goal.
>
> 2. Maintaining a single ordered response flow I_T nexus abstraction to the 
(Continue reading)

Black_David | 3 Jun 14:51 2005

RE: ABORT TASK vs ABORT TASK SET

Mallikarjun,

> I am concerned that the current lack of detailed specification would
> allow targets that might even cause silent data corruptions 
> to qualify as RFC 3720-compliant.
> 
> Here are what I believe to be semantics applicable to all TMF requests
> that can potentially terminate multiple tasks.  I do not know the IETF 
> process well enough here, but I suggest that we consider this text 
> replacing the existing section 10.6.2 in RFC 3720 - so the new text can 
> cover all the TMFs that can impact multiple tasks.  This is basically a 
> superset of the current 10.6.2 semantics.

IETF does have an errata process, but (IMHO) it's not a great venue
for something like this that it's important for implementers to pay
attention to.  What I would suggest is that we start an Internet-Draft
that is intended to become an Implementers Guide RFC (standards track)
to include both technical corrections like this one, and explanations
of subtle points such as how to deal with (what appear to be) REPORT
LUNS overruns as discussed here earlier.  An available example is that
an implementers guide draft is being maintained for SCTP (see
draft-ietf-tsvwg-sctpimpguide-13.txt) although I'd like to believe that
an iSCSI implementers guide won't grow to that size.

For this task management issue, explaining what the problem is and why
the change fixes it in an implementers guide is at least as important as
specifying the change.  For the REPORT LUNS overruns, the implementers
guide text would be an explanation of why no change is needed, including
some elaboration on the (less than completely obvious) SPC-2 text that
specifies the behavior of REPORT LUNS in this circumstance.  Before I
(Continue reading)

Eddy Quicksall | 3 Jun 18:45 2005
Picon
Picon

Re: ABORT TASK vs ABORT TASK SET

If you are going to write this guide, I would like to suggest that a 
paragraph be added saying something like "the initiator and target are not 
expected to catch all protocol errors introduced by the other party and it 
is the implementers option as to which errors may be caught due to internal 
dynamics, crash dynamics or data corruption".

Eddy

----- Original Message ----- 
From: <Black_David <at> emc.com>
To: <cbm <at> rose.hp.com>; <ips <at> ietf.org>
Sent: Friday, June 03, 2005 8:51 AM
Subject: RE: [Ips] ABORT TASK vs ABORT TASK SET

> Mallikarjun,
>
>> I am concerned that the current lack of detailed specification would
>> allow targets that might even cause silent data corruptions
>> to qualify as RFC 3720-compliant.
>>
>> Here are what I believe to be semantics applicable to all TMF requests
>> that can potentially terminate multiple tasks.  I do not know the IETF
>> process well enough here, but I suggest that we consider this text
>> replacing the existing section 10.6.2 in RFC 3720 - so the new text can
>> cover all the TMFs that can impact multiple tasks.  This is basically a
>> superset of the current 10.6.2 semantics.
>
> IETF does have an errata process, but (IMHO) it's not a great venue
> for something like this that it's important for implementers to pay
> attention to.  What I would suggest is that we start an Internet-Draft
(Continue reading)


Gmane