From: P@draigBrady.com
To: Robert Olsson <Robert.Olsson@data.slu.se>
Cc: Harald Welte <laforge@netfilter.org>, netdev@oss.sgi.com
Subject: Re: TX performance of Intel 82546
Date: Wed, 15 Sep 2004 14:59:30 +0100 [thread overview]
Message-ID: <41484AC2.8090408@draigBrady.com> (raw)
In-Reply-To: <16712.14153.683690.710955@robur.slu.se>
Robert Olsson wrote:
> P@draigBrady.com writes:
> > Harald Welte wrote:
>
> > > I'm currently trying to help Robert Olsson improving the performance of
> > > the Linux in-kernel packet generator (pktgen.c). At the moment, we seem
> > > to be unable to get more than 760kpps from a single port of a 82546,
> > > (or any other PCI-X MAC supported by e1000) - that's a bit more than 51%
> > > wirespeed at 64byte packet sizes.
>
> Yes it seems intel adapters work better in BSD as they claim to route
> 1 Mpps and we cannot even send more ~750 kpps even with feeding the
> adapter only. :-)
>
> > In my experience anything around 750Kpps is a PCI limitation,
> > specifically PCI bus arbitration latency. Note the clock speed of
> > the control signal used for bus arbitration has not increased
> > in proportion to the PCI data clock speed.
>
> Yes data from an Opteron @ 1.6 GHz w. e1000 82546EB 64 byte pkts.
>
> 133 MHz 830 pps
> 100 MHz 721 pps
> 66 MHz 561 pps
Interesting info thanks!
It would be very interesting to see the performance of PCI express
which should not have the bus arbitration issues.
> So higher bus bandwidth could increase the small packet rate.
>
> So is there a difference in PCI-tuning BSD versus Linux?
> And even more general can we measure the maximum numbers
> of transactions on a PCI-bus?
>
> Chip should be able to transfer 64 packets in single burst I don't now
> how set/verify this.
Well from the intel docs they say "The devices include a PCI interface
that maximizes the use of bursts for efficient bus usage.
The controllers are able to cache up to 64 packet descriptors in
a single burst for efficient PCI bandwidth usage."
So I'm guessing that increasing the PCI-X burst size setting
(MMRBC) will automatically get more packets sent per transfer?
I said previously in this thread to google for setpci and MMRBC,
but what I know about it is...
To return the current setting(s):
setpci -d 8086:1010 e6.b
The MMRBC is the upper two bits of the lower nibble, where:
0 = 512 byte bursts
1 = 1024 byte bursts
2 = 2048 byte bursts
3 = 4096 byte bursts
For me to set 4KiB bursts I do:
setpci -d 8086:1010 e6.b=0e
The following measured a 30% throughput improvement (on 10G)
from setting the burst size to 4KiB:
https://mgmt.datatag.org/sravot/TCP_WAN_perf_sr061504.pdf
Pádraig.
next prev parent reply other threads:[~2004-09-15 13:59 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-15 8:14 TX performance of Intel 82546 Harald Welte
2004-09-15 9:18 ` P
2004-09-15 12:18 ` jamal
2004-09-15 14:02 ` Harald Welte
2004-09-15 14:46 ` jamal
2004-09-15 14:55 ` Andi Kleen
2004-09-15 12:36 ` Robert Olsson
2004-09-15 13:49 ` jamal
2004-09-15 15:33 ` Robert Olsson
2004-09-15 13:59 ` P [this message]
2004-09-15 15:41 ` Robert Olsson
2004-09-15 18:15 ` Harald Welte
2004-09-15 18:15 ` David S. Miller
2004-09-15 17:55 ` Harald Welte
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=41484AC2.8090408@draigBrady.com \
--to=p@draigbrady.com \
--cc=Robert.Olsson@data.slu.se \
--cc=laforge@netfilter.org \
--cc=netdev@oss.sgi.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).