Re: proposal to fix ordering problem in PCI 2.1

[dvj@apple.com (David V. James)]

My belief is that it is in everyone's best interest
(including Apple) to fix this known problem. However,
I haven't checked with our powers-that-be, so initial discussion
should be viewed as a personal, not corporate, position.

The basic problem is that the PCI designers are slowly adopting
well understood split-response design techniques. Its not that
these techniques aren't well known, its simply that they aren't
usually considered by the designers of (what initially appears
to be) simple unified-response buses, such as PCI.

I agree with HP, that the current PCI proposal for delayed reads
has a fundamental flaw. The basic problem is that of two active
readers, where the two reads (readA and readB) are separated in
time and the read responses (i.e. the data) are falsely affiliated:
  responseB ==> readA-request
  responseA ==> readB-request

The proposal from HP has correctly observed that this can occur
in not-that-unusual software scenarios. I could add a few more
examples, that include DMA adapters fetching and executing
stale command entries. However, if the previous examples were
insufficient to force a progression from the denial phase,
I doubt that one (or a few) more examples would really help.

There is no easy way to ensure that software will never have
the occassion to use stale data returned by a delayed read.
Suggestions that this is a "bad practice" and should not
occur ignore practical realities. Arguments that it is
"rarely" likely to occur are more valid. However, those types
of errors that are rare are the worst kind: they cannot be
easily detected, are rarely repeatable, and typically
occur only at your most-valued customer's site.

The proposed suggestion is to tag the data and only return the
response to the initiating requester. That is the solution that
is used on existing systems and mimics the behavior of a
true split-response bus. As such, it appears to be a valid
solution (not simply a patch) and should be seriously considered.
The potential remaining gotcha is to accurately specify timeouts,
so that:
  1) The response data is not held forever (if requester is reset).
  2) The response data is discarded before a requester has the
     chance to be reset and then generate a second matching request.

These are related to split-response timeouts. If proper affiliation
and timeout strategies are provided, the data transport will be safe.

David V. James
dvj@apple.com


Ó¬3™3