On Tue, Sep 30, 2008 at 09:54:02PM -0600, Matthew Wilcox wrote: > 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. Good point. I had forgotten the first section: +1. About this guide + +This guide describes the basics of Message Signaled Interrupts (MSIs), +the advantages of using MSIs over traditional interrupt mechanisms, how +to change your driver to use MSI or MSI-X and some basic diagnostics to +try if a device doesn't support MSIs. I still believe part of "how to use MSIs correctly" means understanding what DMA Read/Write's are and how they interact with MSI transactions. > 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. Agreed - it had good info - just alot more than needed for the above goal. > I think it would be great if we had a Documentation/PCI/ordering > document ;-) You'd be amused to know I started writing one about two years ago... I'll revisit that in the next month or so and post it for review. I'll include interactions with MSI as part of that. > > 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. Heh. You are very persistent. :) Good enough. > > > 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 ;-) Maybe...but then the networking driver interface were rearchitected to handle that 1% case (NAPI). So someone besides me cares about it. > > 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. Yup - that's dumbed down enough. :) Can you post the whole thing again please? cheers, grant > > -- > 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
