linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: benh@kernel.crashing.org
Cc: Suresh Siddha <suresh.b.siddha@intel.com>,
	Matthew Wilcox <matthew@wil.cx>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"grundler@parisc-linux.org" <grundler@parisc-linux.org>,
	"mingo@elte.hu" <mingo@elte.hu>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"jgarzik@pobox.com" <jgarzik@pobox.com>,
	"linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>,
	"jbarnes@virtuousgeek.org" <jbarnes@virtuousgeek.org>,
	"rdunlap@xenotime.net" <rdunlap@xenotime.net>,
	"mtk.manpages@gmail.com" <mtk.manpages@gmail.com>
Subject: Re: Multiple MSI, take 3
Date: Sun, 13 Jul 2008 15:30:43 -0700	[thread overview]
Message-ID: <m1iqv9a030.fsf@frodo.ebiederm.org> (raw)
In-Reply-To: <1215848161.7549.166.camel@pasglop> (Benjamin Herrenschmidt's message of "Sat, 12 Jul 2008 17:36:01 +1000")

Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:

> I still mostly dislike the new approach, I prefer Matthew's original one
> with SW masking of the MSIs. For example, if you have the MSIs be 'one'
> interrupt, then you hit all of the logic in the IRQ core to make sure
> only one happens at once. Might not be what you want, and -will- cause
> some to be dropped... not nice.

You are correct.  Using the existing irq handling logic will cause us
to drop irqs and to loose information if two messages are sent close
to each other.  Which is very nasty.

With a little care we can avoid that problem by having a 32 bit bitmap
of which sub irqs have fired so we can make all of them pending
without loosing information.  That does requires a new handle_irq method.

One of the primary purposes of masking irqs in hardware is to prevent
them from screaming.  Unlikely with edge triggered irqs but not a capability
I would like to give up.

Multi-msi has the problem that cpu affinity can not be changed on a
per message basis without an iommu.  Which is a portability problem
and a problem on common architectures.

Therefore to support multi-msi it must be handled as a special case, we can not
treat the individual messages like normal irqs.

Eric

  reply	other threads:[~2008-07-13 22:32 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-11  0:57 Multiple MSI, take 3 Matthew Wilcox
2008-07-11  0:59 ` [PATCH] PCI MSI: Replace 'type' with 'is_msix' Matthew Wilcox
2008-07-11  0:59 ` [PATCH] PCI: Add support for multiple MSI Matthew Wilcox
2008-07-11  8:28   ` Hidetoshi Seto
2008-07-11  9:45     ` Matthew Wilcox
2008-07-12  3:45     ` Benjamin Herrenschmidt
2008-07-11  1:00 ` [PATCH] Rewrite MSI-HOWTO Matthew Wilcox
2008-09-26  6:42   ` Grant Grundler
2008-07-11  1:00 ` [PATCH] AHCI: Request multiple MSIs Matthew Wilcox
2008-07-11  1:00 ` [PATCH] x86-64: Support for " Matthew Wilcox
2008-07-11  4:50   ` Kenji Kaneshige
2008-07-11  8:50     ` Matthew Wilcox
2008-07-14  1:08       ` Kenji Kaneshige
2008-07-11 10:06 ` Multiple MSI, take 3 Eric W. Biederman
2008-07-11 10:23   ` Matthew Wilcox
2008-07-11 10:32     ` David Miller
2008-07-11 10:41       ` Matthew Wilcox
2008-07-11 11:05     ` Eric W. Biederman
2008-07-11 11:34     ` Eric W. Biederman
2008-07-11 12:17       ` Matthew Wilcox
2008-07-11 15:10         ` Matthew Wilcox
2008-07-11 21:59   ` Suresh Siddha
2008-07-11 22:59     ` Eric W. Biederman
2008-07-11 23:15       ` Suresh Siddha
2008-07-11 23:59         ` Eric W. Biederman
2008-07-12  3:52       ` Benjamin Herrenschmidt
2008-07-12  4:41         ` Eric W. Biederman
2008-07-12  7:36           ` Benjamin Herrenschmidt
2008-07-13 22:30             ` Eric W. Biederman [this message]
2008-07-13 22:44               ` Benjamin Herrenschmidt
2008-07-13 23:29                 ` Eric W. Biederman
2008-07-14  0:17                   ` Benjamin Herrenschmidt
2008-07-14  0:44                     ` David Miller
2008-07-14  2:03                       ` Eric W. Biederman
2008-07-14  3:19                         ` David Miller
2008-09-26  5:30 ` Jike Song
2008-09-27 19:04   ` 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=m1iqv9a030.fsf@frodo.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=benh@kernel.crashing.org \
    --cc=grundler@parisc-linux.org \
    --cc=jbarnes@virtuousgeek.org \
    --cc=jgarzik@pobox.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=matthew@wil.cx \
    --cc=mingo@elte.hu \
    --cc=mtk.manpages@gmail.com \
    --cc=rdunlap@xenotime.net \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    /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;
as well as URLs for NNTP newsgroup(s).