I am now a little clear on this topic (, I hope).
Originally, it was very questionable for me that the target must
resend the "entire" buffer though the target is sending data over
very reliable (acknowledged) 1394 transactions.
If the initiator can keep the contents of buffer, the target only
needs to resend outstanding transaction(s).
I thought this avoids redundant re-transmission on the wire while
allowing utilization of buffer beyond the target resource.
Whether the initiator keeps the contents of buffer or not depends on
the underlying implementation on the initiator (i.e. interpretation
on the buffer's "direction" bit set to one).
So I would like to propose an enhancement to the recovery model based
on the "MAX_T2I_DATA_SIZE" to take advantage of shared memory model
while keeping independence of implementations.
The enhancement is based on negotiated MAX_T2I_DATA_SIZE reflecting
initiator's preference.
The definition of MAX_T2I_DATA_SIZE will look like following;
MAX_T2I_DATA_SIZE provided by the target indicates the maximum unit
of target-to-initiator data the target can guarantee to hold and
re-send in case of recovering requeued TRANSPORT_T2I_DATA command.
Initiator may set this parameter value smaller than the value
provided by the target. The value zero specified by the initiator
indicates that the target needs not to guarantee to hold and
re-send data beyond 1394 transaction.
Target shall guarantee to hold and re-send data up to this
(negotiated) parameter size.
Responsibility to hold the contents of buffer beyond this parameter
size belongs to the initiator.
The initiator shall avoid to issue TRANSPORT_T2I_DATA command which
has associated buffer larger than this parameter in case that the
buffer contents may not be held.
Though this enhancement will not be optimal in the spirit of shared
memory model, I think almost the same result will be derived by this
enhancement.
Ueda-san from Canon will make a presentation on this enhancement at
upcoming Toronto meeting.
BTW, MAX_I2T_DATA_SIZE parameter seems not to be useful at all for
both ends, and should be gone. Any objections?
Akihiro Shimura
On Mon, 27 Jul 1998 09:26:16 -0700 (PDT)
Greg Shue <gregs@sdd.hp.com> wrote:
> > On Fri, 24 Jul 1998 09:32:52 -0700 (PDT)
> > Greg Shue <gregs@sdd.hp.com> wrote:
> >
> > > 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?
>
> Perhaps the better description is that these parameters _clarify_
> transport behavior. They communicate how the data can/will be moved
> across the wire. This information can be used by both the target
> and intiator protocol drivers in order to more efficiently manage
> it's own resources. If this information was not communicated,
> the behavior of information transfer across the wire would still
> be the same, but much more memory may be reserved for buffering than
> is ever used.
>
> > 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.
>
> Essentially, you are correct. These parameters only make sense
> when you start to consider memory usage optimizations on both intiator
> and target ends. Without these numbers (other than for zero/non-zero
> values), memory could be very unequally allocated by each end.
>
> > > 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.
>
> I don't think that an SBP-2 target can require that the same
> physical memory be tied to a requeued TRANSPORT_T2I_DATA ORB.
> So a target must assume that the memory does NOT contain any
> previously written data, and so must rewrite the entire valid
> contents. The size of the acutal data being transported may
> always be less than the indicated MAX_T2I_DATA_SIZE (unless
> the max size is 1 Byte!). The actual minimum valid data size
> is 1 byte. It still takes a 1 quadlet transaction.
>
> > On the other hand, above statement implies the size of buffer pointed
> > by the ORB itself.
>
> Yes, the MAX size is the maximum size of the buffer pointed to
> by the ORB itself.
>
> > So, this description seems to me to be conflicting.
> >
> > I may be still missing something. Any suggestion?
>
> Yes, can someone else try to describe this? Unfortunately, I am
> as confused with your misunderstandings as you are with my
> descriptions!
>
> > 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.