Re: MSI, fun for the whole family

[Jeff Garzik <jeff@garzik.org>]

Roland Dreier wrote:
> I think you've fundamentally misunderstood what the PCI spec for MSI
> multi message means.  It is true that if the whole system agrees, then

You seem to be ignoring a key usage...


> an MSI-capable device that supports multiple messages might be allocated
> a range of vectors (MSI is kind of stupid because it only allows
> multiple messages to be generated by varying the low order bits -- MSI-X
> fixes this limitation).  However, the way that these different messages
> are handled is that they are all independent interrupt vectors.
> 
> Now, it is true that the kernel could do something crazy and collapse
> all these interrupt vectors into a single "IRQ" and then tell the
> interrupt handler which vector it was by passing some "metadata" in, but
> why not just give each MSI message it's own IRQ?

The answer is:  the driver might prefer to see the message as it 
arrived, rather than dividing it up into independent vectors.  The 
message itself is a unit of data consistency, and there is value in 
letting the driver see the bounds of that unit.

As it stands now, we only a spray of $N function calls for each message, 
with no notion of "we started processing this set of messages" and "we 
ended processing[...]"

Additionally the bitmask-friendly multi-port architecture of these SATA 
controllers matches nicely with an activity (event) status mask we 
already obtain in almost every driver.

Don't assume that the way Linux supports this stuff today is the best, 
or the only way to do things.  It's not "collapsing all these interrupt 
vectors" -- remember that an expansion occurred, and /avoiding 
expansion/ into multiple vectors for multiple messages may be an optimal 
path for a specific driver application.

	Jeff