IO_INTERRUPT_MESSAGE_INFO

NTDEV
1

Hi all,

From a Storport Miniport driver, I wonder how it can access the information of IO_INTERRUPT_MESSAGE_INFO? The Storport driver calls IoConnectInterruptEx and has all the related information, however, it seems storport miniport driver has no way to reference it? Could somebody shed some light on this?

Thanks.

2

I think StorPortGetMSIInfo should get you what you need.

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@ntdev…
> Hi all,
>
> From a Storport Miniport driver, I wonder how it can access the
> information of IO_INTERRUPT_MESSAGE_INFO? The Storport driver calls
> IoConnectInterruptEx and has all the related information, however, it
> seems storport miniport driver has no way to reference it? Could somebody
> shed some light on this?
>
> Thanks.
>

3

Thank you very much, Scott.
StorPortGetMSIInfo returns most of the IO_INTERRUPT_MESSAGE_INFO. However, the most important thing I am looking for is the TargetProcessorSet per vector entry, which provides me the mapping between vectors and processors.

4

I don’t see any way to get at that info (the trouble with abstractions,
they’re great until they don’t provide something you want). Maybe someone
else will have an idea.

In the meantime, why do you need this? Maybe there’s another way to do what
you need.

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@ntdev…
> Thank you very much, Scott.
> StorPortGetMSIInfo returns most of the IO_INTERRUPT_MESSAGE_INFO. However,
> the most important thing I am looking for is the TargetProcessorSet per
> vector entry, which provides me the mapping between vectors and
> processors.
>

5

Thanks, Scott. The one-to-one mapping between vector and processor allow my driver to avoid lockings and have better I/O performance.

6

wrote in message news:xxxxx@ntdev…
> Thanks, Scott. The one-to-one mapping between vector and processor allow
> my driver to avoid lockings and have better I/O performance.
>

I have not much thought about the storage stack but generally I would say
that avoiding locking is not a good idea unless you can have a guarantee
that the affinity that is requested will be granted.

You might still build in the locking in case your affinity requests are not
honered and your routines run concurrently on mutiple processors (and not to
crash out). In case your routines run on the same processor you are not
going to have much contention anyway so the locking impact should be
minimal.

There exist filter drivers which filter IRP_MN_START_DEVICE and there change
the affinity in the allocated resource descriptiors.

Also in latest OSes there are registry policies for assigning interrupt
affinities:
http://msdn.microsoft.com/en-us/library/ff547969.aspx

Just to say that IoConnectInterrupt is not the only place where affinities
are decided.

//Daniel