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
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.
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
So in the end, allowing notify to be clear has no value to PCs and little
John Nels Fuller
Program Manager, Windows 2000
One Microsoft Way
Redmond, WA 98052-6399
Voice: (425) 703-3863
Fax: (425) 93 MSFAX
From: Akihiro Shimura [mailto:firstname.lastname@example.org]
Sent: Wednesday, April 07, 1999 5:42 AM
Subject: P1394> "Notify" bit issue
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
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 (email@example.com) Office Imaging Products Development Center 3 CANON INC.