From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Johannes Stezenbach <js@sig21.net>
Cc: Jamie Lokier <jamie@shareable.org>,
linux-embedded@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: 100Mbit ethernet performance on embedded devices
Date: Fri, 28 Aug 2009 18:35:13 +0100 [thread overview]
Message-ID: <20090828173511.GA4422@sirena.org.uk> (raw)
In-Reply-To: <20090828144138.GB7375@sig21.net>
On Fri, Aug 28, 2009 at 04:41:38PM +0200, Johannes Stezenbach wrote:
> On Thu, Aug 20, 2009 at 02:56:49PM +0200, Johannes Stezenbach wrote:
> > which came with the 2.6.20 kernel. The delay between irq ->
> > netif_rx_schedule() -> NET_RX_SOFTIRQ -> ->poll() doesn't seem
> > to be long enough. But of course my understanding of NAPI is
> > very limited, probably I missed something...
> It would've been nice to get a comment on this. Yeah I know,
> old kernel, non-mainline driver...
> On this platform NAPI seems to be a win when receiving small packets,
> but not for a single max-bandwidth TCP stream. The folks at
> stlinux.com seem to be using a dedicated hw timer to delay
> the NAPI poll() calls:
> http://www.stlinux.com/drupal/kernel/network/stmmac-optimizations
> This of course adds some latency to the packet processing,
> however in the single TCP stream case this wouldn't matter.
Does your actual system have any appreciable CPU loading? If so that
will normally have the same effect as inserting a delay in the RX path.
Some of the numbers will often look worse with NAPI when the system is
lightly loaded (though not normally throughput).
next prev parent reply other threads:[~2009-08-28 17:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-19 14:50 100Mbit ethernet performance on embedded devices Johannes Stezenbach
2009-08-19 15:05 ` Ben Hutchings
2009-08-19 15:35 ` Jamie Lokier
2009-08-20 12:56 ` Johannes Stezenbach
2009-08-28 14:41 ` Johannes Stezenbach
2009-08-28 17:35 ` Mark Brown [this message]
2009-08-29 7:05 ` Simon Holm Thøgersen
2009-08-27 15:38 ` H M Thalib
2009-08-28 14:26 ` Johannes Stezenbach
2009-09-02 5:09 ` Aras Vaichas
2009-09-02 19:35 ` David Acker
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=20090828173511.GA4422@sirena.org.uk \
--to=broonie@opensource.wolfsonmicro.com \
--cc=jamie@shareable.org \
--cc=js@sig21.net \
--cc=linux-embedded@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/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).