All of lore.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 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.