P1394 Mail Archive: Re: STREAM_COMPLETION (Was Re: P1394> Revised PWG1394 Cmd Set)

P1394 Mail Archive: Re: STREAM_COMPLETION (Was Re: P1394> Revised PWG1394 Cmd Set)

Re: STREAM_COMPLETION (Was Re: P1394> Revised PWG1394 Cmd Set)

Greg Shue (gregs@sdd.hp.com)
Mon, 27 Jul 1998 08:48:56 -0700 (PDT)

> Greg -
>
> You didn't discuss the STREAM_COMPLETION variable in your
> "Revised PWG1394 CMD Set note, although I'm guessing it's
> related to the question I raised (and my subsequent action
> item) about whether there needs to be some negotiation over
> strategies for pre-maturely completing stream-oriented ORBs.
> (See page 8 of PWG 1394 Transport Command Set Proposal Rev.
> 0c: TO BE DETERMINED - When else should a target complete
> this command? (e.g. "Flush" requested from target's
> transport client; the target can no longer retain the data
> for retransmission).)

You are correct. I didn't. It should be in a final draft.

> host and device. As I understand it, "message-based
> communication" implies that the initiator knows when
> the target has data to send, but doesn't necessarily
> know the length of the data.

The model we have been using is that a message is a
bounded set of data to be transferred within one ORB.
It is to be transferred as a composite whole, and may
be transferred at any time. The idea is best described
as a "reliable point-to-point datagram service". So the
receiver doesn't know when a message will come or how
long it is. It just knows the maximum length of any single
message, and that the whole message will be transferred
within one ORB. The size of the message is limited by
primarily by the command set used, and otherwise limited
by the packet negotiation size (if the command set takes
care of de/fragmentation).

> "Stream-based
> communication" allows more initiation on the part of
> the target, so that the initiator must post a Store
> Data ORB, to support the possibility that the target
> will have data to transfer.

A STORE DATA (or TRANSPORT_I2T_DATA) ORB will have to
be posted whether it's a message or stream connection.
It's the only means to move data from the Target to the
Initiator. :-)

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

> So, what was the intent for the STREAM_COMPLETION
> variable? Is there something I'm missing related
> to the early completion of Store Data Commands
> for stream-based communication?

If commands are completed immediately, then extra bus
bandwidth is consumed for having to requeue additional
ORBs.

Does this help?

> --
> Bob Morford (bob@sismicro.com)
> SIS Microelectronics, Inc.
> A Subsidiary of Aspec Technology, Inc.
> 1831 Lefthand Cir., Suite #E
> Longmont, CO 80501
> 303-776-1667 x226
>

-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------