netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).