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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.