PSARC/2008/628 Interrupt Resource Management

[Paul Durrant]

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.
==============================