From: "Jan Beulich" <JBeulich@suse.com>
To: Alexander Gordeev <agordeev@redhat.com>
Cc: mingo@elte.hu, jgarzik@redhat.com, linux-ide@vger.kernel.org
Subject: Re: regarding your patch "AHCI: Support multiple MSIs"
Date: Thu, 11 Apr 2013 14:20:46 +0100 [thread overview]
Message-ID: <5166D4CE02000078000CC776@nat28.tlf.novell.com> (raw)
In-Reply-To: <20130410154202.GA2137@dhcp-26-207.brq.redhat.com>
>>> On 10.04.13 at 17:42, Alexander Gordeev <agordeev@redhat.com> wrote:
> On Wed, Apr 10, 2013 at 04:05:30PM +0100, Jan Beulich wrote:
>> Alexander,
>>
>> I'm a bit puzzled by the way ahci_init_interrupts() works, when
>> looking at a particular hardware implementation having 6 ports
>> but allowing up to 16 MSIs - obviously, with one IRQ per port,
>> obtaining 8 MSIs would be sufficient in this case, conserving on
>> resources. Is there any reason this can't be done (i.e. by the
>> caller of pci_enable_msi_block_auto() passing in the maximum
>> desired number)?
>
> There are few points here.
>
> 1. Some (all?) hardware implementations (i.e. Intel) have stupid
> logic that falls back to single MSI mode as if MRSM bit was set,
> in case # of allocated MSIs is less than # of available MSIs,
> even though # of allocated MSIs >= # of ports. I did not find any
> chips which could perform otherwise and stuck with this simpler
> mode for now.
>
> 2. I did implement the approach you described - you can look at it
> in my earlier versions of the patchset. But I withdrew the change,
> since an update to the generic MSI code was needed, and it would be
> hard to convince people to accept changes that nobody consumes.
Just checked this, and indeed it behaves the way you describe.
And actually, the ICH specification also describes this in sufficient
detail, in particular stating that the value 011 (for 8 MSIs) is
reserved, causing undefined behavior when used. As odd as it
is, it looks like we need to live with the 10 wasted vectors...
> 3. If you aware of any hardware that is able sending multiple MSIs
> while the condition holds true:
> # of ports <= # of allocated MSIs < # of available MSIs
> ...I can revive my changes and post it upstream.
We'll have to see how other devices behave - many express root
ports allow for using 2 MSIs (but clearly there's no room for
wasting vectors here).
Jan
prev parent reply other threads:[~2013-04-11 13:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-10 15:05 regarding your patch "AHCI: Support multiple MSIs" Jan Beulich
2013-04-10 15:42 ` Alexander Gordeev
2013-04-10 15:50 ` Jan Beulich
2013-04-10 16:32 ` Alexander Gordeev
2013-04-10 16:36 ` Jan Beulich
2013-04-11 13:20 ` Jan Beulich [this message]
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=5166D4CE02000078000CC776@nat28.tlf.novell.com \
--to=jbeulich@suse.com \
--cc=agordeev@redhat.com \
--cc=jgarzik@redhat.com \
--cc=linux-ide@vger.kernel.org \
--cc=mingo@elte.hu \
/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