P1394 Mail Archive: Re: P1394> MAX_?2?_DATA_SIZE(Was Re: Revised PWG1394 Cmd Set)

Re: P1394> MAX_?2?_DATA_SIZE(Was Re: Revised PWG1394 Cmd Set)

Greg Shue (gregs@sdd.hp.com)
Mon, 27 Jul 1998 09:26:16 -0700 (PDT)

>
>
> 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
----------------------------------------------------------------