Is there anyone who can explain how MSI-X is supposed to help give
affinity performance improvements under Storport? I’ve read all docs
that I can find three times and still don’t understand it. Seems the
problem is that Storport I/O is likely to be randomly assigned to
different processors, but the devices I’ve got docs on all want to be
configured once at startup and write to the same MSI-X entry every time
(unless I’m reading that wrong).
So as a miniport, I have no way to match up the incoming I/O to the
processor that handled it on the way out. That means a cache hit and
that’s not cool.
I see that there’s an interface for modifying the MSI-X table entries
and that seems to be the piece that’s missing, but according to docs
there’s no corresponding functionality in Storport.
Have I got this whole thing wrong? I sure feel like I do. What’s the
trick to get everyone to play nice?
John,
If your devices expect to interrupt using the same MSI-X message every time regardless of the originating processor, then my understanding is that you won’t be able to take advantage of interrupt redirection.
To use interrupt redirection, the miniport tells Storport which range of MSI-X messages should be used for interrupt redirection, and then Storport allocates those message numbers among the various NUMA nodes / processors. When the miniport’s StartIo entry point is called, the miniport calls StorPortGetStartIoPerfParams to obtain the MSI-X message that Storport recommends for the I/O: the MSI-X message that’s been assigned to the originating NUMA node / processor. The miniport is then responsible for conveying that MSI-X message number to the hardware, in some way linking the I/O request to that MSI-X message number. Then, when the I/O completes, the hardware must use the linked MSI-X message to ensure that the desired node/CPU responds to the interrupt.
– Keith