WDf Interrupt Policy

Hi

I am using WdfInterruptSetPolicy. I can see below m_XXX members has the new policy values I set.
But IoResourceDescriptor->Flags has CM_RESOURCE_INTERRUPT_POLICY_INCLUDED bit set and thus escapes the if block.
I am creating WDFINTERRUPT object is AddDevice() and do not have any InterruptAffinity\AssignmentOverride registry keys set.
Please let me know in case you see anywhere it is when/how/being set.

FxInterrupt::FilterResourceRequirements(
  //
    // Apply policy.  Only do this if we are running on an OS which supports
    // the notion of Interrupt Policy and if the policy is not already included
    // by the bus driver based on registry settings.
    //
    if (FxLibraryGlobals.IoConnectInterruptEx != NULL &&
        m_SetPolicy &&
        (IoResourceDescriptor->Flags & CM_RESOURCE_INTERRUPT_POLICY_INCLUDED) == 0x0) {

        IoResourceDescriptor->Flags |= CM_RESOURCE_INTERRUPT_POLICY_INCLUDED;
        IoResourceDescriptor->u.Interrupt.AffinityPolicy      = (IRQ_DEVICE_POLICY)m_Policy;
        IoResourceDescriptor->u.Interrupt.PriorityPolicy      = (IRQ_PRIORITY)m_Priority;
        IoResourceDescriptor->u.Interrupt.TargetedProcessors  = m_Processors.Mask;
        IoResourceDescriptor->u.Interrupt.Group               = m_Processors.Group;
    }
}

thanks

Most likely the ‘policy’ is already set by the bus device providing the
interrupt resource and you cannot change it.

Mark Roddy

As an aside, I spent some time trying to change the interrupt policy for a PCI device that was supported by a WDF driver I was developing. I was never successful in doing it. I eventually had to abandon the effort, because I ran out of play time (and changing the interrupt policy was never anything but a lame attempt to work around a platform integration issue in any case). But I just wanted to note that changing the policy was not nearly as straight forward as I expected it to be.

Mark
When in windbg, I cleared that flag, everything works. All my MSI-X vectors get the policy I individually applied to each vector/interrupt.
For me it looks like that flag should be set only when driver INF has AssignmentSetOverride reg key.

Peter
Trying this again to deal a case of tput/perf under hybrid cores scenario.

https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/interrupt-affinity-and-priority

For me it looks like that flag should be set only when driver INF has AssignmentSetOverride reg key.

Well that is one way, but any bus or lower filter driver associated with the PDO can also set the flag before you get at it, right?

Are you trying to apply a policy that will route your interrupts to performance cores only?

As is always the case with performance, there is an interesting discussion to be had here I think. It seems sure that in direct benchmarks of your device’s throughput, this would be beneficial, but it seems less clear that this would help overall system performance

The way that the chipset handles interrupts and the way that the scheduler operates - both factors beyond your control - would seem to be more important factors. But the world of asymmetric multi processing is a very interesting one

@Mark_Roddy said:
Well that is one way, but any bus or lower filter driver associated with the PDO can also set the flag before you get at it, right?
In my case I do not have a lower filter. And bus (pci.sys) should not be doing that for the API contract to workw?

@MBond2 said:
It seems sure that in direct benchmarks of your device’s throughput, this would be beneficial,
yes just for lab purpose


I was able to make this work with the other method, filter-resource (Though not by just modifying resources in place, like WDM way IRP filter resources suggests). So I delete all resources and add them back with the policies I want. But MSDN has below.

The framework calls the driver’s EvtDeviceRemoveAddedResources callback function immediately before it passes the device’s resource list to the bus driver. This callback function removes added resources so that the bus driver will not attempt to use them.

I do not delete the ones I added, then everything works. I can policy my interrupts the way I want. Please let know what above means?

Just FYI, there is always a lower filter driver in a pci stack. acpi.sys is on the stack. Go take a look.

@Mark_Roddy said:
Just FYI, there is always a lower filter driver in a pci stack. acpi.sys is on the stack. Go take a look.
Thanks, I missed this.

If this is just for a test in your lab, then why worry about any warnings that MSDN might have