From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Prodyut Hazarika <phazarika@amcc.com>
Cc: Victor Gallardo <vgallardo@amcc.com>, Feng Kan <fkan@amcc.com>,
netdev@vger.kernel.org, lada.podivin@gmail.com,
Loc Ho <lho@amcc.com>,
bhutchings@solarflare.com, linuxppc-dev@lists.ozlabs.org,
davem@davemloft.net
Subject: RE: [PATCH 1/2] ibm_newemac: Add Support for MAL Interrupt Coalescing
Date: Tue, 22 Sep 2009 10:07:07 +1000 [thread overview]
Message-ID: <1253578027.7103.177.camel@pasglop> (raw)
In-Reply-To: <0CA0A16855646F4FA96D25A158E299D606FFE7FF@SDCEXCHANGE01.ad.amcc.com>
On Mon, 2009-09-21 at 16:49 -0700, Prodyut Hazarika wrote:
> Hi Ben,
> Thanks for your comments.
>
>
> > What happens if we build a kernel that is supposed to boot with two
> > different variants of 405 or 440 ?
>
> We cannot build a kernel with H/W Interrupt coalescing other than in
> 405EX/460EX/GT.
> This is controlled via KConfig (config IBM_NEW_EMAC_INTR_COALESCE
> depends on IBM_NEW_EMAC && (460EX || 460GT || 405EX))
> Is this approach acceptable (via Kconfig)?
No. That's my point. All of this must be runtime options. The kernel
must be buildablt for 460EX -and- 460GT - and an old 440EP if I want to
in a single image, and this -with- the coalescing option enabled. It
would obviously only be available when running on the cores that support
it, but it should -not- be a compile time decision.
IE. All your ifdef's should be turned into runtime checks. If you have
conflicting #define for register names and bits, then prefix them with
the SoC name.
The only acceptable compile-time option is to have the ability to not
compile the coalescing support at all, thus avoiding bloat when building
configs that are only targeted toward processors that don't have it or
setups that don't want it.
> > There are existing mechanisms via ethtool to configure coalescing. You
> > should hookup onto these.
>
> I will start looking at the ethtool options
Thanks.
Cheers,
Ben.
next prev parent reply other threads:[~2009-09-22 0:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-21 22:47 [PATCH 1/2] ibm_newemac: Add Support for MAL Interrupt Coalescing Prodyut Hazarika
2009-09-21 23:41 ` Benjamin Herrenschmidt
2009-09-21 23:49 ` Prodyut Hazarika
2009-09-22 0:07 ` Benjamin Herrenschmidt [this message]
2009-09-22 0:05 ` Prodyut Hazarika
2009-09-22 0:12 ` Benjamin Herrenschmidt
2009-09-22 0:28 ` prodyut hazarika
2009-09-22 0:39 ` Benjamin Herrenschmidt
2009-09-22 0:53 ` Prodyut Hazarika
2009-09-22 1:09 ` Benjamin Herrenschmidt
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=1253578027.7103.177.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=bhutchings@solarflare.com \
--cc=davem@davemloft.net \
--cc=fkan@amcc.com \
--cc=lada.podivin@gmail.com \
--cc=lho@amcc.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=netdev@vger.kernel.org \
--cc=phazarika@amcc.com \
--cc=vgallardo@amcc.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;
as well as URLs for NNTP newsgroup(s).