> Greg Shue wrote:
> >
> > > I think the question to be answered is whether there needs
> > > to be negotiation between target and initiator (or maybe
> > > just information from target to initiator) over when, under
> > > stream-based comm., the target is allowed to complete the
> > > Store Data Orb. As I thought about this, the only reasons
> > > that I identified for termination were application
> > > related. And the application (transport client in the
> > > device) seemed to have it's own good reason.
> >
> > This is the essence of the issue. In Stream-based communication,
> > a target could complete an ORB:
> >
> > as soon as _any_ data is available (possibly wasting bus
> > bandwidth)
> >
> > only when it must (full or target internally blocked because
> > output must be sent before proceeding).
> >
> > or anywhere in between.
>
> It seems that the second case must be determined by the application
> (transport client). If you allow the application to decide, then
> is there really any point in negotiation?
>
> Was this the point of "STREAM_COMPLETION" or did you have something
> else in mind?
The point was some policy needed to be defined to have consistent
implementations. I just couldn't make the call on my own about
where that responsibility lies or what the policy should be.
If the policy becomes that the target will pass along as much
data as it can as quickly as it can it may be sufficient. (Though
we could end up with many small transactions rather than a few large
ones when data trickles out.)
As long as you can get people to agree on something, it's probably
fine with me. :-)
-- Greg Shue Hewlett-Packard Company All-in-One Division gregs@sdd.hp.com ----------------------------------------------------------------