On Fri, Nov 22, 2013 at 01:44:47PM -0500, Tejun Heo wrote:
> +int pcim_enable_msi_range(struct pci_dev *dev, struct msix_entry *entries,
> + unsigned int nvec, unsigned int minvec)
> +
> +This variation on pci_enable_msi_block() call allows a device driver to
> +request any
On Fri, Nov 22, 2013 at 07:44:30PM +0100, Alexander Gordeev wrote:
> On Wed, Nov 20, 2013 at 12:15:26PM -0500, Tejun Heo wrote:
> > The use of @nvec and @maxvec is a bit inconsistent. Maybe it'd be
> > better to make them uniform?
>
> With @maxvec I tried to stress an implication there could be v
On Wed, Nov 20, 2013 at 12:15:26PM -0500, Tejun Heo wrote:
> The use of @nvec and @maxvec is a bit inconsistent. Maybe it'd be
> better to make them uniform?
With @maxvec I tried to stress an implication there could be values
less than @maxvec. While @nvec is more like an exact number.
Perfectly
On Thu, Oct 24, 2013 at 11:51:58AM +0100, Tejun Heo wrote:
Hi Tejun,
> I haven't looked into any details but, if the above works for most use
> cases, it looks really good to me.
Could you please take a look (at least) at patches 10 and 12?
> tejun
--
Regards,
Alexander Gordeev
agord...@redha
On 13-10-25 06:01 AM, Alexander Gordeev wrote:
>
> If this problem really exists anywhere besides pSeries?
>
> I can imagine x86 hitting lack of vectors in interrupt table when
> number of CPUs exceeds hundreds, but do we have this problem now?
An awful lot of x86 hardware has a 256 (255?) vector
On Fri, 2013-10-25 at 12:01 +0200, Alexander Gordeev wrote:
> On Fri, Oct 25, 2013 at 10:10:02AM +0100, David Laight wrote:
> > What this doesn't resolve is a driver requesting a lot of interrupts
> > early on and leaving none for later drivers.
>
> If this problem really exists anywhere besides p
On Fri, Oct 25, 2013 at 10:10:02AM +0100, David Laight wrote:
> What this doesn't resolve is a driver requesting a lot of interrupts
> early on and leaving none for later drivers.
If this problem really exists anywhere besides pSeries?
I can imagine x86 hitting lack of vectors in interrupt table
> > pcim_enable_msix_min_max(struct pci_dev *dev, struct msix_entry *entries,
> > unsigned int minvec, unsigned int maxvec);
>
> The hardware I have in mind here works only for powers of two.
> Eg. 16, 8, 4, 2, or 1 MSI-X vector. Not the odd values in between.
>
> But it app
On 13-10-24 10:31 AM, Alexander Gordeev wrote:
> On Thu, Oct 24, 2013 at 11:51:58AM +0100, Tejun Heo wrote:
>> I haven't looked into any details but, if the above works for most use
>> cases, it looks really good to me.
>
> Well, if we reuse Michael's statistics:
>
> - 58 drivers call pci_enable
On 13-10-24 07:41 AM, Alexander Gordeev wrote:
> On Thu, Oct 24, 2013 at 11:57:40AM +0100, David Laight wrote:
>> The one case it doesn't work is where the driver either
>> wants the full number or the minimum number - but not
>> a value in between.
>>
>> Might be worth adding an extra parameter so
On Thu, Oct 24, 2013 at 11:51:58AM +0100, Tejun Heo wrote:
> I haven't looked into any details but, if the above works for most use
> cases, it looks really good to me.
Well, if we reuse Michael's statistics:
- 58 drivers call pci_enable_msix()
- 24 try a single allocation and then fallback to
On Thu, Oct 24, 2013 at 11:57:40AM +0100, David Laight wrote:
> The one case it doesn't work is where the driver either
> wants the full number or the minimum number - but not
> a value in between.
>
> Might be worth adding an extra parameter so that this
> (and maybe other) odd requirements can b
Hello,
On Thu, Oct 24, 2013 at 11:57:40AM +0100, David Laight wrote:
> > > ...would turn into a single helper call
> > >
> > > rc = pcim_enable_msix_range(adapter->pdev,
> > > adapter->msix_entries,
> > > nvec,
> > >
> > ...would turn into a single helper call
> >
> > rc = pcim_enable_msix_range(adapter->pdev,
> > adapter->msix_entries,
> > nvec,
> > FOO_DRIVER_MINIMUM_NVEC);
>
> I haven't looked into any de
Hello, Alexander.
On Fri, Oct 18, 2013 at 07:12:12PM +0200, Alexander Gordeev wrote:
> So i.e. the request loop described in the documentation...
>
> int foo_driver_enable_msix(struct foo_adapter *adapter,
> int nvec)
> {
> while (nvec >=
Currently many device drivers need contiguously call functions
pci_enable_msix() for MSI-X or pci_enable_msi_block() for MSI
in a loop until success or failure. This update generalizes
this usage pattern and introduces pcim_enable_msi*() family
helpers.
As result, device drivers do not have to dea
16 matches
Mail list logo
