Thank you for the comments.
Please see the comments embedded below …
Akihiro Shimura
On Wed, 7 Apr 1999 10:31:15 -0700
John Nels Fuller <jfuller@MICROSOFT.com> wrote:
> Hi,
>
> 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
> otherwise.
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
> certain.
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
peer's overhead.
> 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.
Any comments?
> -----Original Message-----
> From: Akihiro Shimura [mailto:shimura@pure.cpdc.canon.co.jp]
> Sent: Wednesday, April 07, 1999 5:42 AM
> To: p1394@pwg.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
> 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.
>
>
-- Akihiro Shimura (shimura@pure.cpdc.canon.co.jp) Office Imaging Products Development Center 3 CANON INC.