So there are two possible answers:
1. A target can put anything it wants in the R2T LUN field, and the
initiator must use that value from the R2T in its Data Out, or
I tend to think that the original intent of the spec was Paul's #1. However, in hindsight, the spec should have used the "must" in Paul's description which it unfortunately it did not. To Bill who originally asked the question, the safe approach thus would be storing more state on the initiator end for queueing R2Ts to be serviced.
Mallikarjun
----- Original Message ----
From: Julian Satran <Julian_Satran@xxxxxxxxxx>
To: Paul Koning <pkoning@xxxxxxxxxxxxxx>
Cc: ips@xxxxxxxx; Sears_Bill@xxxxxxx
Sent: Saturday, January 5, 2008 8:50:16 AM
Subject: RE: LUN field in R2T
Paul, You are right that the current spec "favors" 1. However it does not forbid a "zealous" initiator to check the validity of the LUN. If we would have gone as far as naming it a cookie we would have had to face an interminable discussion about what where the "legal" cookie values. LUN seemed a good enough option fora target that segregates resources based on LU. Julo
| Paul Koning <pkoning@xxxxxxxxxxxxxx>
01/04/08 08:23 PM
|
|
To
| Julian Satran/Haifa/IBM@IBMIL
|
|
cc
| Sears_Bill@xxxxxxx, ips@xxxxxxxx
|
|
Subject
| RE: LUN field in R2T |
|
>>>>> "Julian" == Julian Satran <Julian_Satran@xxxxxxxxxx> writes:
Julian> Bill, This is left to the implementer. I would argue that a
Julian> "liberal" initiator should store the LUN-TTT fields as they
Julian> come and not fill them up.
That doesn't sound right to me.
Something can only be left to the implementer if any of the allowed
choices interoperate. And that is not the case here.
If the target treats the LUN field as an additional identifier along
with the TTT, NOT necessarily the same as the LUN number used in the
original I/O request -- which is what section 10.8.5 clearly permits
-- then the only interoperable initiator behavior is to copy the TTT
AND LUN from the R2T to the Data Out message. If it uses the original
request's LUN instead, it won't interoperate
with a target that picks
its own value for the R2T.
So there are two possible answers:
1. A target can put anything it wants in the R2T LUN field, and the
initiator must use that value from the R2T in its Data Out, or
2. A target must use the original request LUN in the R2T, and the
initiator can either copy the LUN field from the R2T, or use the
LUN it used in the request (since they are the same) when building
its Data Out.
It seems pretty clear to me that the current spec answer is #1. And
the underlying problem is that the field was called "LUN" rather than
"64 bit cookie" or something like that.
>> In a nutshell all I want to know is this: Is it legal for an
>> initiator to set the LUN field in the Data-Out PDU based on what
>> it knows the LUN to be, or MUST the initiator copy the contents of
>> the LUN field from the
received R2T into the Data Out.
>>
>> Example: An initiator negotiates for MaxOutstandingR2T==4. The
>> initiator sends a write command to a target. The initiator
>> receives an R2T and starts sending multiple Data-Out PDUs. The
>> initiator receives 3 more R2Ts but cannot start sending Data-Out
>> PDUs immediately due to outbound resource limitations. The
>> initiator must now store off each R2T request so that it can honor
>> them when resources become available ? otherwise the initiator
>> will need to halt receive processing on the connection. The
>> initiator will probably need to store the Target Transfer Tag,
>> Buffer Offset, and Desired Data Transfer Length for each R2T.
>> Does the initiator need to store the LUN from each R2T as well?
>> Or can it just fill in the LUN in the Data Out PDUs based
on
>> knowing what LUN the command was sent to in the first
>> place?
