All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Alexander Gordeev <agordeev@redhat.com>,
	linux-mips@linux-mips.org, linux-s390@vger.kernel.org,
	linux-pci@vger.kernel.org, x86@kernel.org,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-ide@vger.kernel.org, iommu@lists.linux-foundation.org,
	xen-devel@lists.xenproject.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 1/3] PCI/MSI: Add pci_enable_msi_partial()
Date: Tue, 08 Jul 2014 14:01:30 +1000	[thread overview]
Message-ID: <1404792090.26459.1.camel@concordia> (raw)
In-Reply-To: <20140702202201.GA28852@google.com>

On Wed, 2014-07-02 at 14:22 -0600, Bjorn Helgaas wrote:
> On Tue, Jun 10, 2014 at 03:10:30PM +0200, Alexander Gordeev wrote:
> > There are PCI devices that require a particular value written
> > to the Multiple Message Enable (MME) register while aligned on
> > power of 2 boundary value of actually used MSI vectors 'nvec'
> > is a lesser of that MME value:
> > 
> > 	roundup_pow_of_two(nvec) < 'Multiple Message Enable'
> > 
> > However the existing pci_enable_msi_block() interface is not
> > able to configure such devices, since the value written to the
> > MME register is calculated from the number of requested MSIs
> > 'nvec':
> > 
> > 	'Multiple Message Enable' = roundup_pow_of_two(nvec)
> 
> For MSI, software learns how many vectors a device requests by reading
> the Multiple Message Capable (MMC) field.  This field is encoded, so a
> device can only request 1, 2, 4, 8, etc., vectors.  It's impossible
> for a device to request 3 vectors; it would have to round up that up
> to a power of two and request 4 vectors.
> 
> Software writes similarly encoded values to MME to tell the device how
> many vectors have been allocated for its use.  For example, it's
> impossible to tell the device that it can use 3 vectors; the OS has to
> round that up and tell the device it can use 4 vectors.
> 
> So if I understand correctly, the point of this series is to take
> advantage of device-specific knowledge, e.g., the device requests 4
> vectors via MMC, but we "know" the device is only capable of using 3.
> Moreover, we tell the device via MME that 4 vectors are available, but
> we've only actually set up 3 of them.
> 
> This makes me uneasy because we're lying to the device, and the device
> is perfectly within spec to use all 4 of those vectors.  If anything
> changes the number of vectors the device uses (new device revision,
> firmware upgrade, etc.), this is liable to break.

It also adds more complexity into the already complex MSI API, across all
architectures, all so a single Intel chipset can save a couple of MSIs. That
seems like the wrong trade off to me.

cheers



WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-mips@linux-mips.org, linux-s390@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-pci@vger.kernel.org,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-ide@vger.kernel.org, iommu@lists.linux-foundation.org,
	Alexander Gordeev <agordeev@redhat.com>,
	xen-devel@lists.xenproject.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 1/3] PCI/MSI: Add pci_enable_msi_partial()
Date: Tue, 08 Jul 2014 14:01:30 +1000	[thread overview]
Message-ID: <1404792090.26459.1.camel@concordia> (raw)
In-Reply-To: <20140702202201.GA28852@google.com>

On Wed, 2014-07-02 at 14:22 -0600, Bjorn Helgaas wrote:
> On Tue, Jun 10, 2014 at 03:10:30PM +0200, Alexander Gordeev wrote:
> > There are PCI devices that require a particular value written
> > to the Multiple Message Enable (MME) register while aligned on
> > power of 2 boundary value of actually used MSI vectors 'nvec'
> > is a lesser of that MME value:
> > 
> > 	roundup_pow_of_two(nvec) < 'Multiple Message Enable'
> > 
> > However the existing pci_enable_msi_block() interface is not
> > able to configure such devices, since the value written to the
> > MME register is calculated from the number of requested MSIs
> > 'nvec':
> > 
> > 	'Multiple Message Enable' = roundup_pow_of_two(nvec)
> 
> For MSI, software learns how many vectors a device requests by reading
> the Multiple Message Capable (MMC) field.  This field is encoded, so a
> device can only request 1, 2, 4, 8, etc., vectors.  It's impossible
> for a device to request 3 vectors; it would have to round up that up
> to a power of two and request 4 vectors.
> 
> Software writes similarly encoded values to MME to tell the device how
> many vectors have been allocated for its use.  For example, it's
> impossible to tell the device that it can use 3 vectors; the OS has to
> round that up and tell the device it can use 4 vectors.
> 
> So if I understand correctly, the point of this series is to take
> advantage of device-specific knowledge, e.g., the device requests 4
> vectors via MMC, but we "know" the device is only capable of using 3.
> Moreover, we tell the device via MME that 4 vectors are available, but
> we've only actually set up 3 of them.
> 
> This makes me uneasy because we're lying to the device, and the device
> is perfectly within spec to use all 4 of those vectors.  If anything
> changes the number of vectors the device uses (new device revision,
> firmware upgrade, etc.), this is liable to break.

It also adds more complexity into the already complex MSI API, across all
architectures, all so a single Intel chipset can save a couple of MSIs. That
seems like the wrong trade off to me.

cheers

  parent reply	other threads:[~2014-07-08  4:01 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-10 13:10 [PATCH 0/3] Add pci_enable_msi_partial() to conserve MSI-related resources Alexander Gordeev
2014-06-10 13:10 ` Alexander Gordeev
2014-06-10 13:10 ` [PATCH 1/3] PCI/MSI: Add pci_enable_msi_partial() Alexander Gordeev
2014-06-10 13:10   ` Alexander Gordeev
     [not found]   ` <4fef62a2e647a7c38e9f2a1ea4244b3506a85e2b.1402405331.git.agordeev-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-06-23 20:11     ` Alexander Gordeev
2014-06-23 20:11       ` Alexander Gordeev
2014-06-23 20:11       ` Alexander Gordeev
2014-06-23 20:11   ` Alexander Gordeev
2014-07-02 20:22   ` Bjorn Helgaas
2014-07-02 20:22   ` Bjorn Helgaas
2014-07-02 20:22     ` Bjorn Helgaas
2014-07-03  9:20     ` David Laight
2014-07-03  9:20       ` David Laight
2014-07-03  9:20       ` David Laight
2014-07-03  9:20       ` David Laight
2014-07-04  8:58       ` Alexander Gordeev
     [not found]       ` <063D6719AE5E284EB5DD2968C1650D6D1726BF4E-VkEWCZq2GCInGFn1LkZF6NBPR1lH4CV8@public.gmane.org>
2014-07-04  8:58         ` Alexander Gordeev
2014-07-04  8:58           ` Alexander Gordeev
2014-07-04  8:58           ` Alexander Gordeev
2014-07-04  9:11           ` David Laight
     [not found]           ` <20140704085816.GB12247-hdGaXg0bp3uRXgp2RCiI5R/sF2h8X+2i0E9HWUfgJXw@public.gmane.org>
2014-07-04  9:11             ` David Laight
2014-07-04  9:11               ` David Laight
2014-07-04  9:11               ` David Laight
     [not found]               ` <063D6719AE5E284EB5DD2968C1650D6D1726C717-VkEWCZq2GCInGFn1LkZF6NBPR1lH4CV8@public.gmane.org>
2014-07-04  9:54                 ` Alexander Gordeev
2014-07-04  9:54                   ` Alexander Gordeev
2014-07-04  9:54                   ` Alexander Gordeev
2014-07-04  9:54               ` Alexander Gordeev
2014-07-07 19:26             ` Bjorn Helgaas
2014-07-07 19:26               ` Bjorn Helgaas
2014-07-07 19:26               ` Bjorn Helgaas
     [not found]               ` <CAErSpo7QWc35seoMhJA+H1_=MkKWYMdeYG=hT=i1v=iz8d5ezA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-07-08  8:33                 ` David Laight
2014-07-08  8:33                   ` David Laight
2014-07-08  8:33                   ` David Laight
2014-07-08  8:33                   ` David Laight
2014-07-08  8:33                   ` David Laight
2014-07-08  8:33               ` David Laight
2014-07-07 19:26           ` Bjorn Helgaas
2014-07-03  9:20     ` David Laight
     [not found]     ` <20140702202201.GA28852-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2014-07-04  8:57       ` Alexander Gordeev
2014-07-04  8:57         ` Alexander Gordeev
2014-07-04  8:57         ` Alexander Gordeev
     [not found]         ` <20140704085741.GA12247-hdGaXg0bp3uRXgp2RCiI5R/sF2h8X+2i0E9HWUfgJXw@public.gmane.org>
2014-07-07 19:40           ` Bjorn Helgaas
2014-07-07 19:40             ` Bjorn Helgaas
2014-07-07 19:40             ` Bjorn Helgaas
2014-07-07 20:42             ` Alexander Gordeev
2014-07-08 12:26             ` Alexander Gordeev
     [not found]             ` <CAErSpo6f6RXWv0DEtLBZX0jXoSUYJeWrSm7mubSJ_F-O7tQp6w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-07-07 20:42               ` Alexander Gordeev
2014-07-07 20:42                 ` Alexander Gordeev
2014-07-07 20:42                 ` Alexander Gordeev
2014-07-08 12:26               ` Alexander Gordeev
2014-07-08 12:26                 ` Alexander Gordeev
2014-07-08 12:26                 ` Alexander Gordeev
2014-07-09 16:06                 ` Bjorn Helgaas
     [not found]                 ` <20140708122606.GB6270-hdGaXg0bp3uRXgp2RCiI5R/sF2h8X+2i0E9HWUfgJXw@public.gmane.org>
2014-07-09 16:06                   ` Bjorn Helgaas
2014-07-09 16:06                     ` Bjorn Helgaas
2014-07-09 16:06                     ` Bjorn Helgaas
     [not found]                     ` <CAErSpo4oiabgoOjsGdWZpCMPnmopK4xRzB2f3tM0AiUFrdhFww-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-07-10 10:11                       ` Alexander Gordeev
2014-07-10 10:11                         ` Alexander Gordeev
2014-07-10 10:11                         ` Alexander Gordeev
2014-07-10 17:02                         ` Bjorn Helgaas
2014-07-10 17:02                         ` Bjorn Helgaas
2014-07-10 17:02                           ` Bjorn Helgaas
2014-07-10 10:11                     ` Alexander Gordeev
2014-07-07 19:40         ` Bjorn Helgaas
2014-07-04  8:57     ` Alexander Gordeev
2014-07-08  4:01     ` Michael Ellerman
2014-07-08  4:01     ` Michael Ellerman [this message]
2014-07-08  4:01       ` Michael Ellerman
2014-06-10 13:10 ` Alexander Gordeev
2014-06-10 13:10 ` [PATCH 2/3] PCI/MSI/x86: Support pci_enable_msi_partial() Alexander Gordeev
2014-06-10 13:10 ` Alexander Gordeev
2014-06-10 13:10 ` [PATCH 3/3] AHCI: Use pci_enable_msi_partial() to conserve on 10/16 MSIs Alexander Gordeev
     [not found]   ` <dba9f0f8e9cccd7625d0f3fab94457482e1a2bd7.1402405331.git.agordeev-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-06-18 18:54     ` Tejun Heo
2014-06-18 18:54       ` Tejun Heo
2014-06-18 18:54   ` Tejun Heo
2014-06-10 13:10 ` Alexander Gordeev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1404792090.26459.1.camel@concordia \
    --to=mpe@ellerman.id.au \
    --cc=agordeev@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.