From: ebiederm@xmission.com (Eric W. Biederman)
To: Greg KH <greg@kroah.com>
Cc: Mitch Williams <mitch.a.williams@intel.com>,
Michael Ellerman <michael@ellerman.id.au>,
linux-pci@atrey.karlin.mff.cuni.cz, gregkh@suse.de,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
auke-jan.h.kok@intel.com
Subject: Re: [PATCH 2.6.21-rc5] MSI: read-flush MSI-X table
Date: Tue, 27 Mar 2007 07:23:16 -0600 [thread overview]
Message-ID: <m14po6zupn.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20070327000951.GA11555@kroah.com> (Greg KH's message of "Mon, 26 Mar 2007 17:09:51 -0700")
Greg KH <greg@kroah.com> writes:
> On Mon, Mar 26, 2007 at 04:18:22PM -0700, Mitch Williams wrote:
>> This patch fixes a kernel bug which is triggered when using the
>> irqbalance daemon with MSI-X hardware.
>>
>> Because both MSI-X interrupt messages and MSI-X table writes are posted,
>> it's possible for them to cross while in-flight. This results in
>> interrupts being received long after the kernel thinks they're disabled,
>> and in interrupts being sent to stale vectors after rebalancing.
>>
>> This patch performs a read flush after writes to the MSI-X table for
>> enable/disable and rebalancing operations. Because this is an expensive
>> operation, we do not perform the read flush after mask/unmask
>> operations. Hardware which supports MSI-X typically also supports some
>> sort of interrupt moderation, so a read-flush is not necessary for
>> mask/unmask operations.
>>
>> This patch has been validated with (unreleased) network hardware which
>> uses MSI-X.
>
> How well does this play with the MSI core changes that Michael Ellerman
> has proposed on the linux-pci mailing list?
I guess I should add that I'm not certain that the code is exactly correct
there are weird differences between enable/disable and mask. Where generally
the mask/unmask methods do the work and enable/disable do some weird software
thing. Having them different and enable/disable not doing some software
thing concerns me a little. I think mask/unmask may been overoptimized
in this case.
So I expect someone will wind up refactor this code at some point.
However the code is clearly better than what we have now, and it can't
affect anything else.
Eric
next prev parent reply other threads:[~2007-03-27 13:23 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-26 23:18 Mitch Williams
2007-03-27 0:09 ` Greg KH
2007-03-27 2:26 ` Eric W. Biederman
2007-03-27 13:23 ` Eric W. Biederman [this message]
2007-03-27 14:55 ` Grant Grundler
2007-03-27 15:15 ` Eric W. Biederman
2007-03-27 15:25 ` Grant Grundler
2007-03-27 15:31 ` Williams, Mitch A
2007-03-27 16:01 ` Eric W. Biederman
2007-03-27 17:15 ` Williams, Mitch A
2007-03-27 21:13 ` Eric W. Biederman
2007-03-27 21:43 ` Williams, Mitch A
2007-03-28 1:14 ` Eric W. Biederman
2007-03-28 15:37 ` Williams, Mitch A
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=m14po6zupn.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=akpm@linux-foundation.org \
--cc=auke-jan.h.kok@intel.com \
--cc=greg@kroah.com \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
--cc=michael@ellerman.id.au \
--cc=mitch.a.williams@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
all inboxes | Powered by JetHome®