Messages in this thread | | | From | Roland Dreier <> | Subject | Re: MSI, fun for the whole family | Date | Fri, 25 Apr 2008 15:44:40 -0700 |
| |
> 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.
I can't really understand what this is about. As things stand now, each MSI message results in an interrupt, which results in calling the interrupt handler. What information from "the message as it arrived" is being lost other than the precise contents of the PCI transaction, which is system dependent and of no more interest to the driver than what ball number a PCI wire interrupt is hooked up to?
> 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.
I also don't know what you mean about "bitmask-friendly". The AHCI spec that you mentioned pretty clearly talks about having an MSI message per port, rather than putting a bitmask of ports in the message. Given that AHCI supports 32 ports, and MSI messages only are 16 bits long (of which only 5 bits can be changed by the device), I don't see how you expect this bitmask to be encoded.
It seems to me that if the kernel supported multiple MSI messages in the same way it handles multiple MSI-X messages, by giving a different IRQ number for each message, this would be ideal for a driver... you would basically do
for (i = 0; i < dev->num_ports; i++) request_irq(dev->msi_vector[i], port_irq_handler, 0, "name", &dev->port[i]);
and then your interrupt handler could look like
irqreturn_t port_irq_handler(int irq, void *port_ptr) { struct my_port *port = port_ptr; //...
which is very clean and saves you from having to look up any mask of ports.
So it might be nice to handle multiple MSI messages, but it's fairly ugly (both because of the current Linux interrupt handling structure and also because the MSI spec is somewhat broken), but given that most devices are moving to MSI-X, it's not clear that it's worth working on this. And I don't see any reason why MSI would require changes to the IRQ handler prototype.
> 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.
What expansion occurrs? On x86, having a different vector for each MSI message it pretty fundamental to the way the hardware handles interrupts.
- R.
| |