Paul, Features to discover or control interrupt CPU binding are beyond the scope of this project. This project is just managing the number of available interrupts.
Just as I mentioned to David Kahn about how the actual assignment of individual interrupt vectors is done at a different implementation layer, so is the binding of those interrupt vectors to specific CPUs. The interfaces or functionality you're seeking is going to be from some other project or feature. Perhaps intrd, for example. On 10/08/08 02:35, Paul Durrant wrote: > I can't find any mention in the specification of an interface for a > device driver to discover or control interrupt CPU binding. In general, > for a driver with high data throughput, multiple interrupts on the same > CPU are pointless at best and in many cases harmful to performance; in > fact, multiple interrupts using the same CPU core, cache or even > chip/package can be harmful since they may cause needless CPU contention. > So, if a device driver is being given an interface to request more > interrupts then that interface really should allow some control of which > CPUs those interrupts are bound to whether this is specific or by > specification of a policy (e.g. one-per-cpu, one-per-cache, > one-per-chip, etc.). Also, for interrupts allocated using the existing > ddi_intr_alloc() command there really should be a means to discover the > CPU binding unless this call can be superceded by a call that also gives > control over CPU binding for that initial allocation. > > Paul > -- Scott
