Subject: Re: iSCSI - change proposal LUN field definition on every PDU

From: "Julian Satran" <[email-masked]>
Date: Tue, 13 Nov 2001 11:07:58 +0200

Ken,

Yes - that should affect only the PDUs mentioned plus in the Data-Out it 
will be thee even when the data is not in response to an R2T.
Needles to say that this field being mainly for instrumentation targets 
are not supposed to check it for conformance.

Julo

"Ken Sandars" <[email-masked]>
12-11-01 20:19
Please respond to "Ken Sandars"

        To:     <[email-masked]>, Julian Satran/Haifa/IBM@IBMIL
        cc: 
        Subject:        Re: iSCSI - change proposal LUN field definition on every PDU

Hi Julo,

Anything which helps get diagnostic and measurement equipment out
is a GOOD thing, especially when there is a kick back to those who
speak up in support ;-)

Are the only changes to the SCSI Response, the Task Management
Response and the Data-In PDUs?

Cheers,
Ken
[email-masked]
Eurologic Systems
+44 117 930 9616

---

From: "Julian Satran" <[email-masked]>
Date: Tue, 13 Nov 2001 13:00:44 +0200

Santosh,

We are talking about instrumentation that could work based only on what is 
on-the-wire.
For an instrument (software I assume) that sits between SCSI and iSCSI 
this is obviously not an issue.
It is not a major issue for an instrument on the wire (it must maintain 
some state anyhow) but telling something about traffic based on the field 
might simplify it.  We can also make this field "not mandatory to test by 
receiver" to avoid having the receiver pay a penalty.

As for the PDUs - SCSI Response, Data-Out & In and Task Mangement 
request/response.

I am not sure what other uses or side-effects this change may have.

Julo

Santosh Rao <[email-masked]>
Sent by: [email-masked]
12-11-01 20:55
Please respond to Santosh Rao

        To:     Julian Satran/Haifa/IBM@IBMIL
        cc:     [email-masked]
        Subject:        Re: iSCSI - change proposal LUN field definition on every PDU

Julian,

Can you explain further the extent of PDUs that are intended to be
affected by this change ? Also, can you clarify why it is not a problem
for other SCSI transport protocols like FC where the LUN field is not
included in every FC IU ?

IMO, the LUN knowledge is best kept out of the SCSI transport as far as
possible. All LUN level logging/tracing belongs to the SCSI ULP, which
is given a LUN context on each call made to it from the LLP.

At the SCSI LLP layer, tracing/logging as well as state information
should be at the I-T nexus level (session).

I don't (yet) see a sufficient justification for this change. Perhaps,
more information on the motivation for this request may change that.

- Santosh

Julian Satran wrote:
> 
> Dear colleagues,
> 
> A colleague interested in instrumentation approached me with a question
> about stateless logging of specific LU activity.
> With the current iSCSI PDU formats this is not possible.
> We have consistently avoided having fields that are redundant and will
> need consistency checking.
> However I think we should consider including the LU field in all PDUs 
that
> are referencing a specific LU to simplify this type of instrumentation 
(as
> we did with the direction bit in the op-code).
> 
> As I am already in "count-down" mode for version 09 I would appreciate
> your comments ASAP.
> 
> Julo

-- 
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : [email-masked]
Phone : 408-447-3751
##################################