From: Jan-Bernd Themann <ossthema@de.ibm.com>
To: James Chapman <jchapman@katalix.com>
Cc: tklein@de.ibm.com, themann@de.ibm.com, stefan.roscher@de.ibm.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
raisch@de.ibm.com, linuxppc-dev@ozlabs.org, akepner@sgi.com,
meder@de.ibm.com, shemminger@linux-foundation.org,
David Miller <davem@davemloft.net>
Subject: Re: RFC: issues concerning the next NAPI interface
Date: Wed, 29 Aug 2007 10:43:13 +0200 [thread overview]
Message-ID: <200708291043.14380.ossthema@de.ibm.com> (raw)
In-Reply-To: <46D52B14.8010508@katalix.com>
On Wednesday 29 August 2007 10:15, James Chapman wrote:
> Jan-Bernd Themann wrote:
> > What I'm trying to improve with this approach is interrupt
> > mitigation for NICs where the hardware support for interrupt
> > mitigation is limited. I'm not trying to improve this for NICs
> > that work well with the means their HW provides. I'm aware of
> > the fact that this scheme has it's tradeoffs and certainly
> > can not be as good as a HW approach.
> > So I'm grateful for any ideas that do have less tradeoffs and
> > provide a mechanism to reduce interrupts without depending on
> > HW support of the NIC.
> >
> > In the end I want to reduce the CPU utilization. And one way
> > to do that is LRO which also works only well if there are more
> > then just a very few packets to aggregate. So at least our
> > driver (eHEA) would benefit from a mix of timer based polling
> > and plain NAPI (depending on load situations).
>
> Wouldn't you achieve the same result by enabling hardware interrupt
> mitigation in eHEA in combination with NAPI? Presumably a 10G interface
> has hardware mitigation features?
Quote from above: "What I'm trying to improve with this approach
is interrupt mitigation for NICs where the hardware support for
interrupt mitigation is limited"
So guess why I'm doing that ;-)
>
> > If there is no need for a generic mechanism for this kind of
> > network adapters, then we can just leave this to each device
> > driver.
>
> I've been looking at this from a different angle. My goal is to optimize
> NAPI packet forwarding rates while minimizing packet latency. Using
> hardware interrupt mitigation hurts latency so I'm investigating ways to
> turn it off without risking NAPI poll on/off thrashing at certain packet
> rates.
>
> Jan-Bernd, I think I've found a solution to the issue that you
> highlighted with my scheme yesterday and it doesn't involve generating
> other interrupts using hrtimers etc. :) Initial results are very
> encouraging in my setups. Would you be willing to test it with eHEA? I
> don't have a 10G setup. If results are encouraging, I'll post an RFC to
> ask for review / feedback from the NAPI experts here. What do you think?
>
I'm not sure which solution you mean. If you post your RFC, please create
a new thread (other title)
next prev parent reply other threads:[~2007-08-29 8:43 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-24 13:59 RFC: issues concerning the next NAPI interface Jan-Bernd Themann
2007-08-24 15:37 ` akepner
2007-08-24 15:47 ` Jan-Bernd Themann
2007-08-24 15:52 ` Stephen Hemminger
2007-08-24 16:50 ` David Stevens
2007-08-24 21:44 ` David Miller
2007-08-24 21:51 ` Linas Vepstas
2007-08-24 16:51 ` Linas Vepstas
2007-08-24 17:07 ` Rick Jones
2007-08-24 17:45 ` Shirley Ma
2007-08-24 17:16 ` James Chapman
2007-08-24 18:11 ` Jan-Bernd Themann
2007-08-24 21:47 ` David Miller
2007-08-24 22:06 ` akepner
2007-08-26 19:36 ` James Chapman
2007-08-27 1:58 ` David Miller
2007-08-27 9:47 ` Jan-Bernd Themann
2007-08-27 20:37 ` David Miller
2007-08-28 11:19 ` Jan-Bernd Themann
2007-08-28 20:21 ` David Miller
2007-08-29 7:10 ` Jan-Bernd Themann
2007-08-29 8:15 ` James Chapman
2007-08-29 8:43 ` Jan-Bernd Themann [this message]
2007-08-29 8:29 ` David Miller
2007-08-29 8:31 ` Jan-Bernd Themann
2007-08-27 15:51 ` James Chapman
2007-08-27 16:02 ` Jan-Bernd Themann
2007-08-27 17:05 ` James Chapman
2007-08-27 21:02 ` David Miller
2007-08-27 21:41 ` James Chapman
2007-08-27 21:56 ` David Miller
2007-08-28 9:22 ` James Chapman
2007-08-28 11:48 ` Jan-Bernd Themann
2007-08-28 12:16 ` Evgeniy Polyakov
2007-08-28 14:55 ` James Chapman
2007-08-28 11:21 ` Jan-Bernd Themann
2007-08-28 20:25 ` David Miller
2007-08-28 20:27 ` David Miller
2007-08-24 16:45 ` Linas Vepstas
2007-08-24 21:43 ` David Miller
2007-08-24 21:32 ` David Miller
2007-08-24 21:37 ` David Miller
[not found] <8VHRR-45R-17@gated-at.bofh.it>
[not found] ` <8VKwj-8ke-27@gated-at.bofh.it>
2007-08-24 19:04 ` Bodo Eggert
2007-08-24 20:42 ` Linas Vepstas
2007-08-24 21:11 ` Jan-Bernd Themann
2007-08-24 21:35 ` Linas Vepstas
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=200708291043.14380.ossthema@de.ibm.com \
--to=ossthema@de.ibm.com \
--cc=akepner@sgi.com \
--cc=davem@davemloft.net \
--cc=jchapman@katalix.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=meder@de.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=raisch@de.ibm.com \
--cc=shemminger@linux-foundation.org \
--cc=stefan.roscher@de.ibm.com \
--cc=themann@de.ibm.com \
--cc=tklein@de.ibm.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).