Hello, All,
I've made a recovery enhancement proposal document for
TRANSPORT_T2I_DATA command and its parameter to clarify the model.
This document also contains brief example usage.
Ueda-san from Canon will explain this model at Toronto meeting on
my behalf, too.
Please find attached document.
Regards,
Akihiro Shimura
On Fri, 31 Jul 1998 14:20:20 +0900 (JST)
Akihiro Shimura <shimura at pure.cpdc.canon.co.jp> wrote:
> Thank you for the explanation.
>> 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
--
Akihiro Shimura (shimura at pure.cpdc.canon.co.jp)
Office Imaging System Promotion Project
CANON INC.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MaxT2Isz.pdf
Type: application/octet-stream
Size: 8678 bytes
Desc: not available
Url : http://www.pwg.org/archives/p1394/attachments/19980813/31f55746/MaxT2Isz-0001.obj