Artem Kachitchkine wrote: > I'm sponsoring this fasttrack for Scott Carter. It is set to timeout on > 10/15/2008. Given that this is a relatively minor amendment to a larger, > approved case PSARC/2004/253 "Advanced DDI Interrupt Functions", I think > it qualifies as a fasttrack. As the discussion progresses, extending > the timer or even promoting to a full case may be considered. >
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 -- ============================== Paul Durrant Senior Staff Engineer Solarflare Communications Inc. ==============================
