netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Chris A. Icide" <chris@netgeeks.net>
To: Rick Jones <rick.jones2@hp.com>
Cc: netdev@vger.kernel.org
Subject: Re: tg3 driver and interrupt coalescence questions
Date: Tue, 27 Jun 2006 11:55:36 -0700	[thread overview]
Message-ID: <44A17F28.6020802@netgeeks.net> (raw)
In-Reply-To: <44A17A13.8090704@hp.com>

Rick Jones wrote:
>
> Are you looking to increase or decrease the settings?  I would think
> (initially at least) that for VOIP one might not want to increase them.
>
> rick jones
I'm looking to decrease the interrupt load on the system.  During the
test I mentioned above I had some interesting and confusing results. 
The changes from the default settings to the settings I posted resulted
in a 100% performance increase (counted by the number of VoIP audio
streams the tested server could support).  With default settings one of
the two CPUs in the system maxed out at 99% cpu usage handling
interrupts, while the second CPU was not maxed out, but we started to
drop packets and the VoIP call setups started showing retransmits (which
is the measurement for failure in this test) at about 300 streams.  With
the new settings we were able to hit 600 streams.

So I definately recognized a significant improvement.  However I'd still
like to get more improvement.  At 600 streams and 20ms packets we are
looking at 30,000 pps.  The % of cpu (1 CPU as apparently the interrupts
can't be shared across multiple CPUs) used for interrupt handling at
this 600 stream limit was 88.0%.

Now what was interesting was on the test generation side (same hardware
exactly) of things, I was using the SIPP software to generate the VoIP
streams, and each blade in the blade server was only able to generate
~200 streams, with default settings in ethtool, one of the CPUs would
hit max usage for interrupt handling at that point.  So I modified the
ethtool settings to match those I listed above and there was no
discernable difference.  It was identical performance to the default
settings. 

Michael's response clarified for me what the actual parameters in the -C
section of ethtool do, thanks Michael.  However I';; be greatly
appreciative of any recommedations anyone might have for interrupt
mitigation settings for 100% UDP RTP traffic of 20ms packets (50 pps per
stream).

-Chris


  reply	other threads:[~2006-06-27 18:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-27 17:16 tg3 driver and interrupt coalescence questions Chris A. Icide
2006-06-27 17:59 ` Michael Chan
2006-06-27 18:33 ` Rick Jones
2006-06-27 18:55   ` Chris A. Icide [this message]
2006-06-28  5:04     ` Robert Iakobashvili

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=44A17F28.6020802@netgeeks.net \
    --to=chris@netgeeks.net \
    --cc=netdev@vger.kernel.org \
    --cc=rick.jones2@hp.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).