Thank you for the comments.
Please see the comments embedded below $B!D(B
On Wed, 7 Apr 1999 10:31:15 -0700
John Nels Fuller <jfuller@MICROSOFT.com> wrote:
> I think that you will agree that if a target device is allowed to complete
> outstanding ORBs in any arbitrary order that there is no advantage to having
> some ORBs with notify set and others with notify clear since there is no
> relationship between ORBs to give meaning to the ones with notify set. I
> realize that this is not true of the PWG command set, but from the
> perspective of a PC as an initiator where the SBP-2 layer is independent of
> the software layer that knows the device and thus only knows that the device
> gives out of order responses but not why or when then the SBP-2 layer must
> assume random response ordering and is not able to use knowledge of the
> device to imply grouping to the ORBs. Therefore, the PC will always set the
> notify bit for PWG devices even if the PWG command set allows it to be
I agree that completely unordered SBP-2/command set will require
every "notify" bit set.
And, I understand that there will be at least one implementation
which will set every "notify" bit one and of which SBP-2 layer only
accepts completion notification from the bus and never accepts completion
notification (control) from its upper layer.
This will be one of valid implementation choices of PWG command set.
> It is possible that other, less general, initiators can be developed where
> knowledge of the device can be embedded in the SBP-2 driver. However, these
> devices are less likely to be concerned with the overhead of processing each
> completion status and in fact will probably want to limit the number of
> outstanding ORBs per queue to the point where they will need notify set on
> all ORBs anyway.
I suppose this story is a little bit rough.
There will likely be many other (embedded) implementations those
employ modern real time operation system, share processor time with
other processes, and require low overhead. I think whether a device
care about overhead or not is very implementation specific, and we
should not restrict optimization choices of such implementations
>from protocol point of view.
> In any case, if the PWG command set explicitly wants to change this, the
> SBP-2 default is that the target always has the option of returning a status
> for every ORB regardless of the state of the notify bit. This makes any
> gains an initiator might get from the more complex software needed much less
This is another valid implementation choice of PWG command set that
does not care about system level overhead optimization, but I think
this does not lead us to mandating every notify bit set because it
is this specific "implementation" that did not need to care about
> So in the end, allowing notify to be clear has no value to PCs and little
> value elsewhere.
As I described above, the value elsewhere will be varied among
implementations (user(application)'s needs), and I think protocol
specification should not limit this kind of implementer's
optimization choices as far as it does not break anything.
> -----Original Message-----
> From: Akihiro Shimura [mailto:email@example.com]
> Sent: Wednesday, April 07, 1999 5:42 AM
> To: firstname.lastname@example.org
> Subject: P1394> "Notify" bit issue
> Hello, All,
> As noted in the minutes from the March meeting, Brian suggested
> specification change to require that the "notify bit" in ORB be
> always set to one.
> I am still not clear about the reason why this topic needs to be
> re-visited while this topic has already addressed at the July
> meeting last year and agreed not to make any additional, explicit
> statements on this issue other than to follow the SBP-2
> The number of notifications (status blocks) will not affect actual
> data rate on well pipelined implementation because it can be hidden
> behind data transfers if the notification processing is faster than
> data transfers, but will affect the use of processor time in the
> initiator. Interrupt processing like status block reception will
> be very expensive task for the system like PC that shares processor
> time with other processes.
> Setting every "notify" bit one enforces target to explicitly report
> completion of every ORB via status block. But, I think every
> completion is not necessarily to be explicitly reported, and
> mandating to set every "notify" bit one is over-restricting
> implementation choice.
> Because we are relying on the order of ORB's within the queue to
> ensure the in-order delivery, initiator can be informed completion
> implicitly from a status block for succeeding ORB within the queue.
> By receiving the status block for succeeding ORB, initiator can
> safely treat all previous ORB's within the queue as completed with
> predetermined status. Target can also safely treat all status for
> previous ORB's within the queue as sent with predetermined status
> when it sent out status block.
> To make the protocol work without mandating it, we will need to add
> some specification like follows;
> When initiator fills all TASK_SLOTS, there should be at least
> one ORB of which "notify" bit is set for each queue.
> Initiator shall set "notify" bit one on the "final" ORB.
> Initiator shall treat as if all preceding ORB's within the queue
> are completed with predetermined status when status block for
> the queue is received.
> Target shall store status block that contains the status field(s)
> different from predetermined status.
> Target shall treat as if status blocks for all preceding ORB's
> within the queue are stored with predetermined status when
> status block for the queue is stored.
> By specifying rules like above, it seems to work fine without
> mandating to set every "notify" bit one, but I may be missing
> Could someone explain what problem we are trying to solve by
> mandating to set every "notify"?
> Akihiro Shimura
> Akihiro Shimura (email@example.com)
> Office Imaging Products Development Center 3
> CANON INC.
-- Akihiro Shimura (firstname.lastname@example.org) Office Imaging Products Development Center 3 CANON INC.