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
specification.
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
somethings.....
Could someone explain what problem we are trying to solve by
mandating to set every "notify"?
Akihiro Shimura
-- Akihiro Shimura (shimura@pure.cpdc.canon.co.jp) Office Imaging Products Development Center 3 CANON INC.