Multiple MiniportMessageInterruptDPCs on the same CPU

In the following scenario, does NDIS call one
MiniportMessageInterruptDPC per MSI message or just one DPC call?

1. The driver uses two MSI-X messages.
2. MiniportMessageInterrupt always sets QueueDefaultInterruptDpc to
TRUE and returns TRUE.
3. The device sends one MSI message and interrupts a CPU. This causes
a DPC.
4. While the last DPC is either running or is scheduled to run, the
device sends a different MSI message and happens to interrupt the same
CPU. Is this always going to result in another DPC because the
interrupt is due to a different MSI message? Thanks...

Alireza
Fri Feb 02 19:43:52 CST 2007

John, in Vista we allocate one DPC per CPU (and not per MSI message) and
schedule that DPC if you specify the target CPU when you return from ISR or
when you explicitly ask NDIS to schedule a DPC for you.
If your ISR does not ask for a specific target CPU, then we use the default
DPC (which we have one per Miniport). and as you already know, if a DPC has
already been scheduled, it will not be scheduled again.

For LH server we -plan- (no guarantee) to allocate one DPC per message. If
the message is not affinitized with a CPU, we would be allocating one DPC
per message per CPU in order to allow the driver to ask for a DPC for a
particular message on a particular CPU. I am not sure yet, but you may need
to declare your driver to be NDIS 6.1 in order for NDIS to behave this way
instead of "Vista" way.

Please also see my response to your other Email regarding RSS and MSI-X and
feel free to continue this discussion by sending mail to the alias I mention
there.

-ali

--
This posting is provided "AS IS" with no warranties, and confers no rights.

"John" <hykim@rice.edu> wrote in message
news:1170463813.008345.233330@a34g2000cwb.googlegroups.com...
> In the following scenario, does NDIS call one
> MiniportMessageInterruptDPC per MSI message or just one DPC call?
>
> 1. The driver uses two MSI-X messages.
> 2. MiniportMessageInterrupt always sets QueueDefaultInterruptDpc to
> TRUE and returns TRUE.
> 3. The device sends one MSI message and interrupts a CPU. This causes
> a DPC.
> 4. While the last DPC is either running or is scheduled to run, the
> device sends a different MSI message and happens to interrupt the same
> CPU. Is this always going to result in another DPC because the
> interrupt is due to a different MSI message? Thanks...
>

John
Fri Feb 02 20:43:52 CST 2007

On Feb 2, 5:43 pm, "Alireza Dabagh [MS]" <a...@online.microsoft.com>
wrote:
> John, in Vista we allocate one DPC per CPU (and not per MSI message) and
> schedule that DPC if you specify the target CPU when you return from ISR or
> when you explicitly ask NDIS to schedule a DPC for you.
> If your ISR does not ask for a specific target CPU, then we use the default
> DPC (which we have one per Miniport). and as you already know, if a DPC has
> already been scheduled, it will not be scheduled again.
>
> For LH server we -plan- (no guarantee) to allocate one DPC per message. If
> the message is not affinitized with a CPU, we would be allocating one DPC
> per message per CPU in order to allow the driver to ask for a DPC for a
> particular message on a particular CPU. I am not sure yet, but you may need
> to declare your driver to be NDIS 6.1 in order for NDIS to behave this way
> instead of "Vista" way.

Thank you so much for the clarification!

> Please also see my response to your other Email regarding RSS and MSI-X and
> feel free to continue this discussion by sending mail to the alias I mention
> there.

And thanks for this info as well. I will certainly continue
discussion there.