On Tue, Sep 30, 2008 at 04:32:47PM -0600, Grant Grundler wrote: > > Besides, it doesn't have to be an MMIO > > read, it could be a portIO or even config space read. > > True - the doc should say that. Device driver maintainers/writers > should be aware of the options. In fact, because of differences > in master abort handling on "some platforms" between Config space > and MMIO space, I think it's good to include this observation. The purpose of this document is not to teach people how to write a driver correctly, but to teach driver writers how to use MSIs correctly. If it gets turned into part of a larger document, that's fine, but the problem with the original MSI-HOWTO was a complete lack of focus. It included notes on the implementation, advice to people designing hardware, requirements from the PCI spec and random musings on the x86 architecture. I think it would be great if we had a Documentation/PCI/ordering document ;-) > What about the consistent use of terminology? > I don't want people to think "DMA has completed" is something different > than "data reaches memory" (used above). I've eliminated all mention of DMA from the document now, so that shouldn't be a problem. > > 3. Why use MSIs? > > > > There are three reasons why using MSIs can give an advantage over > > traditional pin-based interrupts. > > > > Pin-based PCI interrupts are often shared amongst several devices. > > To support this, the kernel must call each interrupt handler associated > > with an interrupt which leads to increased latency for the interrupt > > handlers which are registered last. > > This is true if the system is idle. > > If the CPU has just started running the last handler, it can take just > as long to get back to the first handler in the list as well. Think of > it as a code loop with the average latency being a function of the size > of the entire loop. > > This is why I was suggesting a less precise statement. True. Though you're looking at the 1% case and I'm looking at the 99% case ;-) How about this: Pin-based PCI interrupts are often shared amongst several devices. To support this, the kernel must call each interrupt handler associated with an interrupt which leads to reduced performance for the system as a whole. MSIs are never shared, so this problem cannot arise. -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
