lkml.org 
[lkml]   [2008]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: MSI, fun for the whole family
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




\
 
 \ /
  Last update: 2008-04-25 06:37    [W:0.096 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site