smp question

Hi there,

  1. Will the Dpc called by ISR always run on the processor running the ISR
    in an SMP system ?
    Will the ISR of a specific interrupt always run on the same processor
    " ?
    How are the interrupt lines connected in an SMP system ? Are they all
    connected to same single processor ?
    What is the Win2000 compatible way for such connection ?

  2. KeQueueDpc() will not queue two calls to the same DPC object , so it
    seems that the way to avoid loosing 2 or more interrupts coming to
    same Dpc is to queue the coming data in a queue/list common to both
    the ISR and the Dpc whose access is coordinated by
    a synchcro routine called by the Dpc and defined via
    KeSynchronizeExecutiion() . Is that so ?

  3. Is there a set of HCT tests to test Win2000 SW driver for smp
    compatiblity or can you give a general hint how to do it ?

thanks,

Dubi

>

  1. Will the Dpc called by ISR always run on the processor
    running the ISR in an SMP system ?

Yes, unless you specifically target a processor for the dpc.

Will the ISR of a specific interrupt always run on the
same processor " ?

No, unless you specifically bind the interrupt object to a specific set of
processors.

How are the interrupt lines connected in an SMP system ?
Are they all connected to same single processor ?
What is the Win2000 compatible way for such connection ?

That all depends on the platform. In general the x86 SMP interrupt
architecture uses APIC type devices to provide programmable interrupt
routing. On most modern SMP x86 platforms interrupts are dispatched by the
APIC interrupt bus to the most available processor rather than fixed to
specific processors.

  1. KeQueueDpc() will not queue two calls to the same DPC
    object , so it seems that the way to avoid loosing 2 or more
    interrupts coming to
    same Dpc is to queue the coming data in a queue/list
    common to both the ISR and the Dpc whose access is coordinated by
    a synchcro routine called by the Dpc and defined via
    KeSynchronizeExecutiion() . Is that so ?

That is one way. Another way is to disable interrupts from your device (in
the ISR,) until the dpc has completed whatever it is doing, which might
include polling the device for all available work. You might want to try
searching this list as there was a fairly interesting discussion of this
topic about a year or so ago.

  1. Is there a set of HCT tests to test Win2000 SW driver for
    smp compatiblity or can you give a general hint how to do it ?

I know of no such smp HCT test. The best way to test for SMP compatability
is (obviously) to run your driver tests on an smp system, the more
processors the better.

> 1. Will the Dpc called by ISR always run on the processor running
the ISR

in an SMP system ?

Yes, unless you have played with DPC’s target processor field.

Will the ISR of a specific interrupt always run on the same
processor
" ?

No, the hardware will distribute them.

How are the interrupt lines connected in an SMP system ? Are they
all
connected to same single processor ?

Read Intel’s CPU documentation on x86 CPUs and APIC. The hardware will
try to distribute them evenly.

  1. KeQueueDpc() will not queue two calls to the same DPC object ,
    so it
    seems that the way to avoid loosing 2 or more interrupts coming to
    same Dpc is to queue the coming data in a queue/list common
    to both
    the ISR and the Dpc whose access is coordinated by
    a synchcro routine called by the Dpc and defined via
    KeSynchronizeExecutiion() . Is that so ?

Yes, though a bitmapped field (an in-memory mirror of the hardware’s
status register) is usually enough, the list is not necessary.

Usually, interrupts indicate that the hardware arrived to some status.
Thus, it is not important whether you will receive 1 or 2 interrupts
on it. Just do not miss the moment when this status bit went to 1.

Max