<html>
<body>
<font size=3>At 07:27 PM 2/1/2005, Roland Dreier wrote:<br>
<blockquote type=cite class=cite cite=""> Michael>
Ordering matrix is documented within the PCIe base 1.0a<br>
Michael> specification. The rules are fairly
straight forward<br>
Michael> depending upon the capabilities being
accessed. Too much<br>
Michael> to type in here but to give you an
idea:<br><br>
Michael> - INTx are treated as writes from a PCIe
transaction<br>
Michael> perspective.<br><br>
Thanks, I had found that matrix. However I was not able to find
any<br>
language about ordering of interrupts and writes outside of the PCI<br>
Express domain -- the question is whether an interrupt could pass a<br>
memory write transaction upstream of the root complex. For
example,<br>
one could imagine a PCIe host bridge for a CPU that has no provision<br>
for in-band interrupt signaling, so the host bridge must signal all<br>
interrupts by asserting an interrupt pin that is independent of the<br>
CPU's memory bus. </font></blockquote><br>
This is a platform / chipset issue and not a PCIe protocol /
specification issue since the problem is outside the scope of the root
complex / root port (RC/RP).<br><br>
<blockquote type=cite class=cite cite=""><font size=3>In this case what
guarantees ordering? Another similar situation would be a PCI-PCIe
reverse bridge where the bridge has to convert PCIe INTx messages to real
PCI interrupt pins -- it seems impossible for any ordering to be
guaranteed.</font></blockquote><br>
Again, this is a platform / chipset issue. A reverse bridge would
be required to maintain the ordering of the PCIe transactions and signal
the PCI/PCI-X INTx accordingly. Given the problem is solved for
PCI/PCI-X at the chipset / platform level, there really isn't anything
that PCIe can do in terms of specification or rules. <br><br>
<br>
<blockquote type=cite class=cite cite=""><font size=3>In fact, section
6.1.3 of the PCIe spec says<br><br>
"Note that similarly to physical interrupt
signals, the INTx emulation mechanism may potentially cause spurious
interrupts that must be handled by the system software."<br><br>
which is conspicuously silent on ordering issues but seems to me to be
saying "watch out."</font></blockquote><br>
It is silent because it is outside the scope of PCIe technology.
The informational note is there to act as a warning for those that may
not be experienced in designing these types of solutions. <br><br>
Let's take a step back and focus on what people believe is a problem for
OpenIB to solve here. What do people believe is the root
cause?<br><br>
Mike<br>
</body>
</html>