add intrmap_one, some temp code to help us write pci_intr_establish_cpu.

it means we can do quick hacks to existing drivers to test interrupts
on multiple cpus. emphasis on quick and hacks.

ok jmat

add intrmap_one, some temp code to help us write pci_intr_establish_cpu.

it means we can do quick hacks to existing drivers to test interrupts
on multiple cpus. emphasis on quick and hacks.

ok jmatthew@, who will also ok the removal of it at the right time.

show more ...

make intrmap_cpu return a struct cpu_info *, not a "cpuid number" thing.

requested by kettenis@
discussed with jmatthew@

add intrmap, an api that picks cpus for devices to attach interrupts to.

there's been discussions for years (and even some diffs!) about how we
should let drivers establish interrupts on multiple cp

add intrmap, an api that picks cpus for devices to attach interrupts to.

there's been discussions for years (and even some diffs!) about how we
should let drivers establish interrupts on multiple cpus.

the simple approach is to let every driver look at the number of
cpus in a box and just pin an interrupt on it, which is what pretty
much everyone else started with, but we have never seemed to get
past bikeshedding about. from what i can tell, the principal
objections to this are:

1. interrupts will tend to land on low numbered cpus.

ie, if drivers try to establish n interrupts on m cpus, they'll
start at cpu 0 and go to cpu n, which means cpu 0 will end up with more
interrupts than cpu m-1.

2. some cpus shouldn't be used for interrupts.

why a cpu should or shouldn't be used for interrupts can be pretty
arbitrary, but in practical terms i'm going to borrow from the
scheduler and say that we shouldn't run work on hyperthreads.

3. making all the drivers make the same decisions about the above is
a lot of maintenance overhead.

either we will have a bunch of inconsistencies, or we'll have a lot
of untested commits to keep everything the same.

my proposed solution to the above is this diff to provide the intrmap
api. drivers that want to establish multiple interrupts ask the api for
a set of cpus it can use, and the api considers the above issues when
generating a set of cpus for the driver to use. drivers then establish
interrupts on cpus with the info provided by the map.

it is based on the if_ringmap api in dragonflybsd, but generalised so it
could be used by something like nvme(4) in the future.

this version provides numeric ids for CPUs to drivers, but as
kettenis@ has been pointing out for a very long time, it makes more
sense to use cpu_info pointers. i'll be updating the code to address
that shortly.

discussed with deraadt@ and jmatthew@
ok claudio@ patrick@ kettenis@

show more ...