Thread (146 messages) 146 messages, 18 authors, 2013-10-15

Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: 2013-10-07 20:13:34
Also in: linux-ide, linux-mips, linux-nvme, linux-pci, linux-rdma, linux-s390, linux-scsi, lkml, netdev

On Mon, 2013-10-07 at 14:01 -0400, Tejun Heo wrote:
I don't think the same race condition would happen with the loop.  The
problem case is where multiple msi(x) allocation fails completely
because the global limit went down before inquiry and allocation.  In
the loop based interface, it'd retry with the lower number.

As long as the number of drivers which need this sort of adaptive
allocation isn't too high and the common cases can be made simple, I
don't think the "complex" part of interface is all that important.
Maybe we can have reserve / cancel type interface or just keep the
loop with more explicit function names (ie. try_enable or something
like that).
I'm thinking a better API overall might just have been to request
individual MSI-X one by one :-)

We want to be able to request an MSI-X at runtime anyway ... if I want
to dynamically add a queue to my network interface, I want it to be able
to pop a new arbitrary MSI-X.

And we don't want to lock drivers into contiguous MSI-X sets either.

And for the cleanup ... well that's what the "pcim" functions are for,
we can just make MSI-X variants.

Ben.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help