When the notify bits are not set, and unordered execution is
possible, SBP-2 does not fully specify a way to always know which
ORBs have been completed. But SBP-2 does allow the target and the
initiator to have such knowledge, learned in application-specific
ways.
Consequently, the Apple SBP-2 services make no attempt to track
whether an ORB is in use or not. This task is given to the device
driver, which may manage ORBs in a way appropriate for the device
it is driving. If your driver and your device can agree on such ORB
usage, our software will allow and support such behavior.
Of course if you set all the notify bits all the time, that will work
too, though it could be wasteful.
--------------------------------------
Eric Anderson ewa@apple.com
Apple Computer, Inc. 408-974-8187
--------------------------------------
>Hi,
>
>Thank you for the comments.
>
>Please see the comments embedded below =C5c
>
>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"?