Re: iSCSI : New PDU opcode usage in rev 5.92

[julian_satran@il.ibm.com]

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" <matt_wakeley@agilent.com> on 20/04/2001 21:11:23

Please respond to Matt Wakeley <matt_wakeley@agilent.com>

To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
cc:   David Black <Black_David@emc.com>
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.).

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.

-Matt Wakeley
Agilent Technologies


julian_satran@il.ibm.com 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 <venkat@rhapsodynetworks.com> on 19/04/2001 07:58:23
>
> Please respond to Venkat Rangan <venkat@rhapsodynetworks.com>
>
> To:   "'Santosh Rao'" <santoshr@cup.hp.com>, ips@ece.cmu.edu
> cc:
> Subject:  RE: iSCSI : New PDU opcode usage in rev 5.92
>
> 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:santoshr@cup.hp.com]
> Sent: Wednesday, April 18, 2001 6:47 PM
> To: ips@ece.cmu.edu
> Subject: iSCSI : New PDU opcode usage in rev 5.92
>
> 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 : santoshr@cup.hp.com
> Phone : 408-447-3751
> #################################