Michael> Ordering matrix is documented within the PCIe base 1.0a
Michael> specification. The rules are fairly straight forward
Michael> depending upon the capabilities being accessed. Too much
Michael> to type in here but to give you an idea:
Michael> - INTx are treated as writes from a PCIe transaction
Michael> perspective.
Thanks, I had found that matrix. However I was not able to find any
language about ordering of interrupts and writes outside of the PCI
Express domain -- the question is whether an interrupt could pass a
memory write transaction upstream of the root complex. For example,
one could imagine a PCIe host bridge for a CPU that has no provision
for in-band interrupt signaling, so the host bridge must signal all
interrupts by asserting an interrupt pin that is independent of the
CPU's memory bus.
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).
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.
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.
In fact, section 6.1.3 of the PCIe spec says
"Note that similarly to physical interrupt signals, the INTx emulation mechanism may potentially cause spurious interrupts that must be handled by the system software."
which is conspicuously silent on ordering issues but seems to me to be saying "watch out."
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.
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?
Mike
_______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
