Thank you for posting the latest revision.
I have additional comments regarding status table now in 7.3 (page
39 of PPDT_r08.pdf).
(I hope this will not open yet another Pandora's box this time.)
Though I guess it is merely forgotten to revise because minutes says
to be revised, but in case of non-zero "sbp_status" with "resp" =
REQUEST_COMPLETE, it may not be possible to report a valid "residual"
for the target and the "residual" field should be unspecified.
For example, in case of "sbp_status" = 2 (speed not supported), it
will be impossible to read a page table to determine the buffer size
because the target need to access the page table with the speed
specified in the "spd" field of the ORB. Other non-zero sbp_status
will fall into similar condition, or otherwise be used only for a
management ORB.
Also in case of "sbp_status" = FF (Unspecified), it seems impossible
to mandate reporting "status" and "residual" because the "sbp_status"
itself says nothing about its cause.
Though other parts seemed okay when I first looked into this table
>from the viewpoint of a possibility for the target to report the
"residual", I have re-examined the table from the viewpoint of a
necessity for the initiator to receive a "residual".
The "residual" in case of "status" = 1 or 2 with "resp" =
REQUEST_COMPLETE will not be necessary for the initiator from the
latter point of view, because the initiator has knowledge of buffer
size by itself, and the result (i.e., no data has been transferred.)
is indicated by the "status" value itself.
I think the "residual" should be unspecified in this case, because
the target may need to do additional transactions to read entire
page table to determine the buffer size, and it merely wastes
bandwidth, etc.
Also, in case of "sbp_status" = 4x (data buffer) with "resp" =
TRANSPORT_FAILURE, I think the "residual" should be unspecified,
because it is not necessary for the initiator (i.e., maintaining an
execution context in the target will be enough to recover from this
condition, and even if the initiator has elected not to recover this
situation, the connection will be released abortively anyway), and
the target may need to do addition transactions redundantly as well
>from the fact that the target may start buffer accesses after
retrieving page table partially.
Regards,
AKihiro Shimura
-- Akihiro Shimura (shimura@pure.cpdc.canon.co.jp) Office Imaging Products Development Center 3 CANON INC.