P1394 Mail Archive: Re: P1394> Print Protocols
Re: P1394> Print Protocols
Greg Shue (
gregs@sdd.hp.com)
Thu, 19 Feb 1998 16:57:18 -0800 (PST)
Jack Hollins (Adaptec) wrote:
>
> Greg Shue wrote:
>
> > > > "Actually, I think it is a bit more complicated."
> > > >
> > > > Flow control:
> > > > If "flow control" refers to the scheduling of bus transactions to
> > > > process a task, then I agree it is done by the (target's) fetch
> > > > agent.
> > > >
> > > > If "flow control" refers to the presentation of the task requests
> > > > (ORBs) and shared memory space then it is managed the initiator,
> > > > since we're talking about one task request (ORB) referring to one
> > > > "packet" transfer.
> > > >
> > >
> > > Actually a single ORB can point to a data buffer which is larger than the
> > > maximumlegal 1394 packet transfer size. Therefore multiple data packet
> > > transfers can be
> > > caused by one ORB.
> >
> > Ah, another case of overloaded terms. Yes, an ORB can refer to
> > a much larger data buffer than the maximum possible MTU of the bus.
> > This results in many MTU transfers per ORB. Thanks for keeping me
> > honest and consistent.
> >
> > I was using "packet" with respect to the transaction layer.
> > I was thinking of the case where a 10 MByte print job is consumed by
> > a device with 1 MByte of buffer space, and the flow of data into the
> > 1 MByte buffer space must be controlled. In this case I was thinking
> > that ORBs with 0.5 MByte to 1 MByte data blocks would be reasonable.
> >
>
> Actually the initiator does not need to be aware of buffer limitations of the
> targetin regards to the initiator sizing the data buffers associated with an
> ORB. A target
> is under complete control of the consumption rate once an ORB has been put in
> the
> initiator's linked list (assuming linked lists are used) or if the ORB pointer
> CSR is
> written in the non-linked list case. This allows different target
> architecture
> performance/cost tradeoffs to be made without impacting an initiator. A more
> cost
> sensitive target might have a smaller buffer space than a higher performance
> target.
This is true if the tasks being processed by the target are
idempotent. (In other words, that they may be executed one or
more times and end up with exactly the same result.) This
feature is needed to support the following situation:
- a task to be partially processed
- a Bus Reset to occur (which implicitly aborts the task)
- the task requeued on the list
- the task completely restarted
I think this is an inheirent attribute of mass storage commands.
Unfortunately, printers are not.
Sending a set of commands which are larger than the printer can
buffer forces the printer to process some commands before they
are all received. If a Bus Reset occurs, then either the printer
must validate that the same ORB was requeued and try to resume
from the last valid offset fetched, OR the protocol can guarantee
that the ORB's data block has been completely transferred before
the data is processed. The first case is difficult at best, the
second is easy and provides idempotency at the cost of
negotiating the maximum sizes of the data blocks referenced by
the ORBs.
So, it's easier for the initiator to be aware of the transport
packet sizes supportable by the target than it is to work around
the Bus Reset problem by another mechanism. If you have a better
suggestion, I'll certainly consider it.
"Need" is relative to the context. In this thread, we're talking
about using SBP-2 for printing services.
--
Greg Shue
Hewlett-Packard Company
Office Products Division gregs@sdd.hp.com
----------------------------------------------------------------