Because transport does not have any knowledge about stream boundary,
I think transport should not have its own completion policy beyond
the flow control, and should follow the client's policy.
For a target, it will be straightforward to follow the client's early
completion request by issuing early completion status to the
initiator.
On the other hand, I think we need some consideration in case of
client's early completion request on the initiator side.
Because SBP-2 works with message queuing (linked list of ORBs) and
initiator does not have knowledge of the place where the target is
executing, the early completion will not be able to be handled within
the initiator, and early completion request needs to go across the
wire to the target.
My concern here is that if we can use "ABORT TASK" management
function for this purpose or we need "TERMINATE TASK" management
function which has gone from the latest SBP-2 specification.
Is there any suggestion?
Akihiro Shimura
On Mon, 27 Jul 1998 10:27:32 -0700 (PDT)
Greg Shue <gregs@sdd.hp.com> wrote:
> Bob Morford (bob@sismicro.com) wrote:
>
> > 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
> ----------------------------------------------------------------
>
-- Akihiro Shimura (shimura@pure.cpdc.canon.co.jp) Office Imaging System Promotion Project CANON INC.