[Top] [All Lists]

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

To: Tejun Heo <>
Subject: Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
From: Benjamin Herrenschmidt <>
Date: Tue, 08 Oct 2013 07:10:56 +1100
Cc: Alexander Gordeev <>, Ben Hutchings <>,, Bjorn Helgaas <>, Ralf Baechle <>, Michael Ellerman <>, Martin Schwidefsky <>, Ingo Molnar <>, Dan Williams <>, Andy King <>, Jon Mason <>, Matt Porter <>,,,,,,,,,,,,,, Solarflare linux maintainers <>, "VMware, Inc." <>,
In-reply-to: <>
List-archive: <>
List-help: <>
List-id: linux-mips <>
List-owner: <>
List-post: <>
List-software: Ecartis version 1.0.0
List-subscribe: <>
List-unsubscribe: <>
Original-recipient: rfc822;
References: <> <> <> <> <> <1381009586.645.141.camel@pasglop> <> <1381040386.645.143.camel@pasglop> <> <>
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.


<Prev in Thread] Current Thread [Next in Thread>