> It was acknowledged at the July meeting that these parameters
> do NOT need to go across the wire in order to have a functioning
> protocol.
>
> A strong desire was expressed to have these parameters go
> across the wire in order for initiator and target to more
> effeciently use their respective memory resources. These
> are there as a concession to that desire.
So, these two parameters do not specify the transport behavior itself
and are only referenced by client application of the initiator, right?
If so, your descriptions seem to me to be misleading.
I feel the descriptions of these parameters sound like followings,
though I am still not sure these descriptions make sense.
MAX_I2T_DATA_SIZE indicates the maximum amount of
initiator-to-target data the client of target is willing to receive
in one buffer. This parameter does not limit buffer size itself,
and may be reported to the client of initiator.
If this value is zero, target shall reject TRANSPORT_I2T_DATA
command.
MAX_T2I_DATA_SIZE indicates the maximum amount of
target-to-initiator data the client of target is willing to send in
one buffer. This parameter does not limit buffer size itself, and
may be reported to the client of initiator.
If this value is zero, target shall reject TRANSPORT_T2I_DATA
command.
> MAX_T2I_DATA_SIZE is the maximum amount of target-to-initiator
> data the target will buffer and retransmit across this
> connection if the Task is implicilty or explicitly aborted
> (e.g. Bus Reset or TASK SET ABORT). Any memory allocated by
>From the error recovery model we discussed, above value may be
smaller than the size of buffer pointed by the ORB, and may minimally
be payload size of block transaction.
> the initiator beyond this amount is wasted, since it will never
> be used. Similarly, if an initiator only provides memory
> buffers much smaller than those indicated by the target, the
> target may be able to manage it's internal memory more
> effeciently.
On the other hand, above statement implies the size of buffer pointed
by the ORB itself.
So, this description seems to me to be conflicting.
I may be still missing something. Any suggestion?
Akihiro Shimura
> MAX_I2T_DATA_SIZE is there for symmetry.
>
> Greg Shue, HP
>
> Akihiro Shimura wrote:
>
> > > B) MAX_I2T_DATA_SIZE (31 bits unsigned int)
> > > C) MAX_T2I_DATA_SIZE (31 bits unsigned int)
> >
> > It is still not clear for me what is specified for initiator and/or
> > target by these parameters.
> >
> > Size of the "buffer" referred by data_descriptor field of an ORB will
> > be determined along with requesting client of the initiator. Once the
> > ORB is appended to task list, access right to the "buffer" is granted
> > to the target, and the "buffer" looks like (remote) receiving/sending
> > buffer of the target. The target can access any part of the "buffer"
> > within the address range of the "buffer" in arbitrary size unit the
> > target wants to handle.
> >
> > I think the size of the "buffer" referred by the ORB and the size
> > unit that target processes the "buffer" are independent of each other.
> >
> > Could you explain why these parameters need to go across the wire?
> >
> > Akihiro Shimura
>
>
> --
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division gregs@sdd.hp.com
> ----------------------------------------------------------------
>
-- Akihiro Shimura (shimura@pure.cpdc.canon.co.jp) Office Imaging System Promotion Project CANON INC.