public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Michael Ellerman <michael@ellerman.id.au>
To: Matthew Wilcox <matthew@wil.cx>
Cc: linux-pci@vger.kernel.org, kaneshige.kenji@jp.fujitsu.com,
	mingo@elte.hu, tglx@linutronix.de, davem@davemloft.net,
	dan.j.williams@intel.com, Martine.Silbermann@hp.com,
	benh@kernel.crashing.org, linux-kernel@vger.kernel.org,
	Matthew Wilcox <willy@linux.intel.com>
Subject: Re: [PATCH 1/4] PCI MSI: Store the number of messages in the msi_desc
Date: Mon, 07 Jul 2008 13:48:32 +1000	[thread overview]
Message-ID: <1215402512.9862.16.camel@localhost> (raw)
In-Reply-To: <20080707024125.GU14894@parisc-linux.org>

[-- Attachment #1: Type: text/plain, Size: 2780 bytes --]

On Sun, 2008-07-06 at 20:41 -0600, Matthew Wilcox wrote:
> On Mon, Jul 07, 2008 at 12:05:24PM +1000, Michael Ellerman wrote:
> > On Sat, 2008-07-05 at 09:34 -0400, Matthew Wilcox wrote:
> > > This first part simply changes the msi_attrib data structure to store
> > > how many vectors have been allocated.  In order to do this, I shrink the
> > > 'type' from 5 bits to 2 and rename it to _type to catch any unsuspecting
> > > users.
> > 
> > Please don't, it significantly uglifies the code IMHO. Just add a new
> > field for the size, I'd rather call it qsize to match the register.
> 
> Uglifies the code?  Seriously?  Other than the _ addition (which really
> I just did to be sure I didn't miss a case), how is MSI_ATTRIB uglier
> than PCI_CAP_ID_MSI?

Yeah seriously :)  The _ is part of it, but MSI_ATTRIB is uglier than
PCI_CAP_ID_MSI exactly because it's not PCI_CAP_ID_MSI, which exists and
is well defined and is used in the rest of the code.

> I'd like to rename the register definition from QSIZE.  It's _not_ a
> queue.  I don't know where this misunderstanding came from, but I
> certainly don't want to spread it any further.

I didn't say it was a queue, but a Q ;)  But I agree it's not a good
name, the spec calls it "multiple message enable", nvec would match the
existing code best, or log_nvec.

> > If you're worried about bloating msi_desc, there's several fields in
> > there that are per-device not per-desc, so we could do another patch to
> > move them into pci_dev or something hanging off it, eg.
> > pci_dev->msi_info rather than storing them in every desc.
> 
> Might be worth it anyway for devices with lots of MSI-X interrupts.

Eventually yeah, last I looked we didn't have any drivers using more
than a few MSI-X, but at some point it will happen.

> I think the MSI-X implementation is a bit poorly written anyway.  If we
> had an array of msi_desc for each device, we could avoid the list_head
> in the msi_desc, for example.  That'd save two pointers (8 or 16 bytes),
> plus the overhead of allocating each one individually.

Yeah that would be nice.

> I also think that MSI-X could be improved by changing the interface to
> do away with this msix_entry list passed in -- just allocate the irqs
> consecutively.

It would be nice, but as I said the other day we have at least one
driver (s2io) which asks for non-consecutive entries. That doesn't
effect the irq allocation, but you need some way for the driver to
express it.

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2008-07-07  3:48 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-03  2:44 Multiple MSI Matthew Wilcox
2008-07-03  3:24 ` Benjamin Herrenschmidt
2008-07-03  3:59   ` Matthew Wilcox
2008-07-03  4:41     ` Benjamin Herrenschmidt
2008-07-03  6:44       ` Michael Ellerman
2008-07-03  9:10         ` Arnd Bergmann
2008-07-03  9:17           ` Benjamin Herrenschmidt
2008-07-03 11:31             ` Matthew Wilcox
2008-07-03 11:41               ` Benjamin Herrenschmidt
2008-07-04  1:52                 ` Michael Ellerman
2008-07-04  8:08                   ` Alan Cox
2008-07-03 11:34       ` Matthew Wilcox
2008-07-07 16:17   ` Grant Grundler
2008-07-07 16:39     ` Matthew Wilcox
2008-07-07 16:51       ` Grant Grundler
2008-07-07 23:06     ` Benjamin Herrenschmidt
2008-07-10  0:55     ` Michael Ellerman
2008-07-05 13:27 ` Matthew Wilcox
2008-07-05 13:34   ` [PATCH 1/4] PCI MSI: Store the number of messages in the msi_desc Matthew Wilcox
2008-07-07  2:05     ` Michael Ellerman
2008-07-07  2:41       ` Matthew Wilcox
2008-07-07  3:26         ` Benjamin Herrenschmidt
2008-07-07  3:48         ` Michael Ellerman [this message]
2008-07-07 12:04           ` Matthew Wilcox
2008-07-07 16:02             ` Grant Grundler
2008-07-07 16:19               ` Matthew Wilcox
2008-07-10  1:32             ` Michael Ellerman
2008-07-10  1:35               ` Matthew Wilcox
2008-07-05 13:34   ` [PATCH 2/4] PCI: Support multiple MSI Matthew Wilcox
2008-07-07  2:05     ` Michael Ellerman
2008-07-07  2:45       ` Matthew Wilcox
2008-07-07  3:56         ` Michael Ellerman
2008-07-07 11:31           ` Matthew Wilcox
2008-07-10  1:32             ` Michael Ellerman
2008-07-10  1:43               ` Matthew Wilcox
2008-07-10  4:00                 ` Michael Ellerman
2008-07-05 13:34   ` [PATCH 3/4] AHCI: Request multiple MSIs Matthew Wilcox
2008-07-07 16:45     ` Grant Grundler
2008-07-07 17:48       ` Matthew Wilcox
2008-07-20  7:49         ` Grant Grundler
2008-07-05 13:34   ` [PATCH 4/4] x86-64: Support for " Matthew Wilcox
2008-07-05 13:43   ` Multiple MSI Matthew Wilcox
2008-07-05 22:38     ` Matthew Wilcox

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=1215402512.9862.16.camel@localhost \
    --to=michael@ellerman.id.au \
    --cc=Martine.Silbermann@hp.com \
    --cc=benh@kernel.crashing.org \
    --cc=dan.j.williams@intel.com \
    --cc=davem@davemloft.net \
    --cc=kaneshige.kenji@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=matthew@wil.cx \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --cc=willy@linux.intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox