tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: RFC: add MSI/MSI-X support to NetBSD



On Fri, Jun 06, 2014 at 07:06:00PM +0000, Taylor R Campbell wrote:
>    Date: Fri, 6 Jun 2014 12:56:53 -0500
>    From: David Young <dyoung%pobox.com@localhost>
> 
>    Here is the proposal that I came up with many months (a few years?) ago
>    with input from Matt Thomas.  I have tried to account for Matt's
>    requirements, but I'm not sure that I have done so.
> 
> For those ignoramuses among us who remain perplexed by the apparent
> difficulty of using a new interrupt delivery mechanism, could you add
> some notes to your proposal about what driver authors would need to
> know about it and when & how one would use it in a driver?

Driver authors do not need to know anything about bus_msi(9) unless
they're doing something fancy.  bus_msi(9) will be invisible to the
author of a PCI driver because pci_intr(9) will establish the mailbox
and all of that.

bus_msi(9) hides differences between hardware platforms.

> Would all architectures with PCI support bus_msi(9), or would PCI
> device drivers need to conditionally use it?  Why isn't it just a
> matter of modifying pci_intr_map, or calling pci_intr_map_msi like in
> OpenBSD?

For a PCI driver, it *is* a matter of calling pci_intr_map(9), or
whatever NetBSD comes up with for MSI/MSI-X.

> Would there be other non-PCI buses with message-signalled
> interrupts too?

It's conceivable that there are existing non-PCI buses that use
message-signalled interrupts.  Any future bus probably will.

> (Still not having done my homework to study what this MSI business is
> all about, I'll note parenthetically that it seems FreeBSD and OpenBSD
> have supported MSI for a while, and I understand neither why it was so
> easy for them nor what advantage they lack by not having bus_msi(9).)

NetBSD has supported MSI (but not MSI-X) for a while, too, at least on
i386 or x86.

Here are the nice things about MSI/MSI-X in a nutshell: you can have
many interrupt sources per device (IIRC, there are just 4 interrupt
lines on a legacy PCI bus), each interrupt can signal a different
condition (so your interrupt service routine doesn't have to read
an interrupt condition register), you can route each condition on a
device to a different CPU, and the interrupt is a bus-master write
that flushes all of the previous bus-master writes by the same device
(according to the PCI ordering rules), so a driver doesn't have to poll
a device register to "land" buffered bus-master writes before examining
descriptor rings and other DMA-able regions.

Dave

-- 
David Young
dyoung%pobox.com@localhost    Urbana, IL    (217) 721-9981


Home | Main Index | Thread Index | Old Index