Subject: iSCSI : New PDU opcode usage in rev 5.92

From: Santosh Rao <[email-masked]>
Date: Wed, 18 Apr 2001 18:47:07 -0700 (PDT)

Julian & All,

I've got a quick question on how the new opcode layouts would work for
dual mode scsi implementations. (i.e. initiators that responded in
target mode or targets that acted as initiators also).

The new opcode layout is :

----------------
X|I| | | | | | |
----------------
7 6 5 4 3 2 1 0

where bits 5-0 -> opcode
X -> retry bit
I -> immediate bit

The same values are used for the command as well as response opcodes and
bits X & I are intended to both be set to 1 by targets.

i.e. opcode for scsi command = scsi response = 0x01. the distinction b/n
command and response is based on targets setting X & I bits to 1.

Now, if an initiator [capable of target mode] sent the following
commands, how would they be interpreted :

1) 0xc4.
is this a text command being retried in immediate mode, 
or is it a text response ?

2) 0xc1
is this a scsi command being retried in immediate mode,
or is it a scsi response ?

3) 0xc2
is this a scsi task mgmt command being retried in immediate mode,
or is it a scsi task mgmt response ?

etc.....

- Santosh

-- 
#################################
Santosh Rao
Software Design Engineer,
HP, Cupertino.
email : [email-masked]
Phone : 408-447-3751
#################################

---

From: Venkat Rangan <[email-masked]>
Date: Wed, 18 Apr 2001 22:58:23 -0700

Santosh,

Is it not the case that requests go in the direction from the Initiator to
Target,
where Target is the one "listening" for new connections on the well-known
port?
A dual mode scsi implementation therefore has two separate sessions and sets
of connections.
One set is [I->DualModeTarget] and the other is [DualModeInitiator->T]
and the connections are independent. If I and T happens to be the same
system, you
can not use a single connection for bidirectional sessions between the two.

So if you receive a PDU from a target, you can only do so with SourcePort
set to
well-known-port, and it must be a Response from target. May be I'm assuming
something
that is not valid...

Venkat Rangan
Rhapsody Networks Inc.
http://www.rhapsodynetworks.com

-----Original Message-----
From: Santosh Rao [mailto:[email-masked]]
Sent: Wednesday, April 18, 2001 6:47 PM
To: [email-masked]
Subject: iSCSI : New PDU opcode usage in rev 5.92

Julian & All,

----------------
X|I| | | | | | |
----------------
7 6 5 4 3 2 1 0

where bits 5-0 -> opcode
X -> retry bit
I -> immediate bit

1) 0xc4.

2) 0xc1

3) 0xc2

etc.....

- Santosh

---

From: [email-masked]
Date: Thu, 19 Apr 2001 20:07:44 +0200

The former bit of differentian is gone. The main reason we had it was for
analyzers. This is also why I choose the bits as I did.
As for the explanation - I'll check what's already in there.

Julo

Santosh Rao <[email-masked]> on 19/04/2001 19:08:10

Please respond to Santosh Rao <[email-masked]>

To:   [email-masked]
cc:
Subject:  Re: iSCSI : New PDU opcode usage in rev 5.92

That's not a restriction other SCSI transports impose. FCP allows both
the initiator and target bit to be set in PRLI indicating dual mode
behaviour within a single I-T nexus.

However, the point I'm trying to make is that the opcode cannot be
interpreted by itself and needs interpretation in the context of the
"role" the receiver is playing. i.e. Opcode parsing must be in
conjunction with the check of the receiver's role (is it receiving the
command while operating as a target or initiator ?)

Seems like such a description is missing in the draft.

- Santosh

[email-masked] wrote:
>
> Santosh,
>
> On a given nexus the roles are static aren't they?
>
> Julo
>
> Santosh Rao <[email-masked]> on 19/04/2001 03:47:07
>
> Please respond to Santosh Rao <[email-masked]>
>
> To:   [email-masked] (ips)
> cc:
 - santoshr.vcf

---

From: [email-masked]
Date: Fri, 20 Apr 2001 16:57:58 -0400

> On another point, I don't think you should be changing things as
fundamental
> as this without direction from the group.  This "standard" is supposed to
be
> stabilizing, not constantly changing.

With my WG co-chair hat on, Matt has a valid point.  Given the stage we're
at
with the base iSCSI specification, any substantive change like this really
needs
to be reviewed on the mailing list before being made, lest we repeat the
drawn-
out experience with the header changes (which were initially made shortly
after the January meeting in Orlando).  At this juncture the right thing to
do is tee this up for discussion in Nashua with a request to Julian to be
more
careful about these sort of changes in the future - even if the technical
reasons
for doing this were 100% correct, not discussing this sort of thing on the
list beforehand risks having to do it over at great length (timewise) and
consternation.

Matt - in case this slips into a crack, please make sure it's brought up
at the Tuesday AM agenda bashing if it doesn't appear on the agenda.

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

---

From: [email-masked]
Date: Sat, 21 Apr 2001 18:04:02 +0200

Matt,

Sorry - I was running late and still hopping to get the recovery done.
As for the matter on hand - If the "fake indication" offered by the 2
initial bits is not good enough
we might reinstate a direction bit and reduce the vendor specific space.

I am sure that David can take this on the list.

Regards,
Julo

"Matt Wakeley" <[email-masked]> on 20/04/2001 21:11:23

Please respond to Matt Wakeley <[email-masked]>

To:   Julian Satran/Haifa/IBM@IBMIL, [email-masked]
cc:   David Black <[email-masked]>
Subject:  Re: iSCSI : New PDU opcode usage in rev 5.92

Julian,

I like the "direction bit".  It is a way to exactly determine what the
message
is, without the need to know the context (especially useful when analyzing
what's happening on the link).

If you think we are running short on opcodes, then don't use a "direction
bit", but just renumber the opcodes for unique values (for example, 0x01 =
command, 0x02 = response, etc.).

-Matt Wakeley
Agilent Technologies

[email-masked] wrote:
>
> I would like to add to Venkat remarks only that this asymmetry has been
> with us in iSCSI forever
> and we had even a statement to the effect that targets should not issue
> initiator codes etc. (this is irrelevant now as the codes overlap).
>
> The reason I took out the "direction bit" (meant more for observers) was
> that I felt that we are low on codes :-)
>
> Julo
>
> Venkat Rangan <[email-masked]> on 19/04/2001 07:58:23
>
> Please respond to Venkat Rangan <[email-masked]>
>
> To:   "'Santosh Rao'" <[email-masked]>, [email-masked]
> cc:
> Subject:  RE: iSCSI : New PDU opcode usage in rev 5.92
>
> Santosh,
>