Quoting r. Michael Krause <[EMAIL PROTECTED]>:
> 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
>
Mike, what do you mean by the root cause?
If the CPU may start serving the interrupt while DMA is not yet committed to memory, we may not rely on the
interrupt/DMA ordering, and its irrelevant whether its PCI-express or chipset issue.
Every driver needs to deal with spurious interrupts irrespective of whether it is a a PCIe or chipset issue. A good h/w / s/w design should not require PIO Read to ascertain whether something real or spurious happened. If that is the only concern, then it does not sound like there is any real problem here only clarification of our reality being sought.
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
