RE: LUN field in R2T

[dcuddihy@xxxxxxxxxxxx]

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



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
_______________________________________________
Ips mailing list
Ips@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ips