Sounds like whatever the intent of the
field was that the spec might be somewhat ambiguous. I’ll err
on the side of caution and make sure the LUN field is copied from the R2T into
the Data-Outs. Personally in neither our initiator or target
implementations do I even look at that LUN field in the R2T or Data-Out since the
ITT and TTT are sufficient for tracking the IO. However I can conceed
that some target implementations may benefit from having the LUN field in the
Data-Out.
Bill
From: dcuddihy@xxxxxxxxxxxx
[mailto:dcuddihy@xxxxxxxxxxxx]
Sent: Friday, January 04, 2008
10:21 AM
To: Paul Koning
Cc: ips@xxxxxxxx;
Julian_Satran@xxxxxxxxxx; Sears, Bill
Subject: RE: LUN field in
R2T
Paul,
Your
comments make sense to me. The initiator *should* copy the lun
over from the R2T. From a practical standpoint I don't think that a
target should rely on the initiator copying that data, since the field is, in
fact, called "LUN" in the data out message.
Further,
I'm not sure that 10.7.4 is clear on this point:
"If the
Target Transfer Tag is
provided, then the LUN field MUST hold a
valid value and be
consistent with whatever was specified with
the command;"
One
could argue that 'command' is generally used in the context of a SCSI command,
not an R2T. To reiterate - It's reasonable to say that an initiator
should copy the data, but I don't think that a target can depend on that
behavior.
regards,
david
say that the
David
J Cuddihy
Principal Engineer
ATTO Technology, Inc.
www.attotech.com
Power Behind the Storage
Paul Koning
<pkoning@xxxxxxxxxxxxxx> wrote on 01/04/2008 09:53:59 AM:
> >>>>> "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?
>
>
>
>
_______________________________________________
> Ips mailing list
> Ips@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/ips
