[openib-general] [PATCH] roland-uverbs: possible race condition

[Michael Krause]

At 07:27 PM 2/1/2005, Roland Dreier wrote:
>     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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20050202/a8a20eb3/attachment.html>