MSI vs MSI-X Explained: How PCIe Devices Signal Interrupts

A PCI or PCIe device needs a way to tell the processor that an event requires software attention. Traditional PCI interrupt signaling uses INTx lines. Message-Signaled Interrupts, or MSI, take a different path: the device performs a write to a special address with data configured by the operating system, and that transaction causes the platform to deliver an interrupt to the processor.

The Linux kernel describes an MSI as a write from a device to a special address that causes the CPU to receive an interrupt. That makes the word “message” easy to misread: this is not an application message, network packet, or ordinary DMA payload. It is an interrupt-signaling transaction defined by the PCI architecture and configured by system software.

Once the platform has configured message-signaled interrupts, a device can use allocated interrupt messages to notify the operating system about work. The resulting interrupt is associated with a vector that the operating system connects to a driver interrupt-service routine. The vector is not a PCIe lane and does not describe link width or transfer bandwidth.

Multiple vectors can let a driver separate different event paths. The Linux MSI documentation gives examples such as assigning distinct interrupts to packet queues on a network adapter or ports on a storage controller. That can reduce the need for one handler to inspect a single shared interrupt source, but the exact number of vectors a device, driver and operating system actually use is a negotiated resource decision rather than a fixed measure of device performance.

MSI was introduced with PCI 2.2, while MSI-X arrived with PCI 3.0. Current Linux kernel documentation describes MSI-X as supporting more interrupts per device and allowing them to be independently configured. Its PCI API can allocate any number of MSI-X vectors between one and 2,048, whereas MSI is limited to a smaller power-of-two set and requires a contiguous allocation.

Windows exposes a similar practical distinction. Microsoft documents multi-message MSI limits as 1, 2, 4, 8, or 16 through its driver installation configuration, while MSI-X can request any number up to 2,048. Microsoft also documents that MSI messages share affinity, whereas MSI-X interrupt resource descriptors can use different affinities. Those are architectural and operating-system allocation differences, not a promise that an MSI-X device will be faster in every workload.

Traditional pin-based PCI interrupts can be shared among devices. The kernel may therefore need to invoke handlers associated with a shared interrupt so software can determine which device needs service. Linux documents MSI vectors as exclusive rather than shared, removing that particular ambiguity for the allocated vector.

PCI ordering also matters. Linux notes that with pin-based signaling, a driver can need a device register read to ensure preceding DMA writes have become visible before handling the interrupt. An MSI write cannot pass earlier data writes under the relevant PCI ordering rules, so the interrupt provides a useful ordering property. This is a protocol-level benefit; it should not be turned into a universal claim about frame rate or end-to-end application latency.

On Windows, hardware support alone does not mean a driver will automatically use message-signaled interrupts in every configuration. Microsoft documents that a driver INF enables MSI support through the device hardware key under Interrupt Management\MessageSignaledInterruptProperties. The MSISupported value tells Windows that the device supports MSI, while MessageNumberLimit can bound how many messages are requested.

That documentation is written for driver installation and development. It is not evidence that users should manually force arbitrary devices into MSI mode with a registry tweak. A device, its firmware, its Windows driver, and the operating system need a compatible interrupt path. Changing undocumented or driver-owned settings without device-specific evidence can produce no benefit or cause malfunction.

A PCIe function can advertise MSI or MSI-X capability, but the operating system still allocates interrupt resources and the driver still has to use them correctly. Linux explicitly allows drivers to request a range of vectors and receive fewer than the maximum the device could theoretically support. Windows likewise tells drivers to check the number of messages that the Plug and Play manager actually allocated.

This is why a specification saying “MSI-X supported” does not establish that 2,048 vectors are active, useful, or even requested. The upper limit describes the mechanism. Real allocations depend on the device design, driver, operating system, platform resources, and workload architecture.

MSI or MSI-X describes how a device signals an interrupt and how interrupt messages can be allocated. After the processor receives an interrupt, operating-system and driver code still has work to do. On Windows that can include an interrupt service routine and deferred processing; on other operating systems the implementation details differ. Slow or excessive driver work is therefore a separate performance problem from the electrical or message-signaling mechanism that raised the interrupt.

The same separation applies to CPU affinity. MSI-X can give software more flexibility to steer different interrupt messages, which is useful for designs such as multiqueue network adapters. Affinity policy, queue mapping, interrupt moderation, driver behavior, CPU load, and the application workload then determine whether that flexibility has a measurable effect.

Receive Side Scaling is a networking mechanism for distributing receive processing across processors. Multiqueue network adapters commonly pair receive queues with interrupt vectors, and MSI-X provides a suitable way to route separate queue interrupts. That relationship is why MSI-X often appears in discussions of high-throughput network adapters.

RSS still has its own queue selection, hashing, processor mapping, driver policy and operating-system behavior. MSI-X supplies interrupt-signaling resources; it does not perform packet hashing or create network bandwidth. Similar reasoning applies to NVMe and other multiqueue devices: multiple vectors can support parallel software paths without becoming a substitute for the device protocol or its queues.

A message-signaled interrupt is transported as a memory write, but that does not mean MSI is another name for DMA. A device may use DMA to move payload data into system memory and then use MSI or MSI-X to notify software that work completed. The data movement and the completion notification are related transactions with different purposes.

Likewise, switching between INTx, MSI and MSI-X does not change a PCIe link from x4 to x8, raise its transfer rate, or create more controller queues. PCIe generation and lane width determine transport capability; device protocols define their own command and data structures; interrupt signaling tells software that an event needs attention. Keeping those layers separate prevents a large class of misleading PC optimization claims.

There are sound architectural reasons for modern drivers to use MSI or MSI-X, and many devices already do so through their supported driver path. That is different from claiming that manually changing interrupt mode will universally increase FPS, reduce input lag, improve SSD throughput, fix audio, or lower network latency. None of those outcomes follows from the interrupt mechanism alone.

Application-visible performance depends on the complete path: device workload, queues, interrupt rate and moderation, driver ISR/DPC behavior, CPU scheduling and affinity, memory and I/O behavior, and the application itself. If a specific driver or hardware vendor documents an interrupt-mode requirement, follow that device-specific guidance. Otherwise, benchmark a clearly defined problem before attributing it to MSI versus MSI-X.