Historic archive of defunct list bloat-devel@lists.bufferbloat.net
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: Rick Jones <rick.jones2@hp.com>
Cc: bloat-devel <bloat-devel@lists.bufferbloat.net>
Subject: Re: oprofiling is much saner looking now with rc6-smoketest
Date: Tue, 30 Aug 2011 18:45:55 -0700	[thread overview]
Message-ID: <CAA93jw6vAZfLz=MUsxMnG0Ku1RPAn65FU5Z+sBh4UYyK0LY8ig@mail.gmail.com> (raw)
In-Reply-To: <4E5D87DD.7040705@hp.com>

On Tue, Aug 30, 2011 at 6:01 PM, Rick Jones <rick.jones2@hp.com> wrote:
> On 08/30/2011 05:32 PM, Dave Taht wrote:

>> It bugs me that iptables and conntrack eat so much cpu for what
>> is an internal-only connection, e.g. one that
>> doesn't need conntracking.
>
> The csum_partial is a bit surprising - I thought every NIC and its dog
> offered CKO these days - or is that something happening with
> ip_tables/contrack?

If this chipset supports it, so far as I know, it isn't documented or
implemented.

> I also thought that Linux used an integrated
> copy/checksum in at least one direction, or did that go away when CKO became
> prevalent?

Don't know.

>
> If this is inbound, and there is just plain checksumming and not anything
> funny from conntrack, I would have expected checksum to be much larger than
> copy.  Checksum (in the inbound direction) will take the cache misses and
> the copy would not.  Unless... the data cache of the processor is getting
> completely trashed - say from the netserver running on the router not
> keeping up with the inbound data fully and so the copy gets "far away" from
> the checksum verification.

220Mbit isn't good enough for ya? Previous tests ran at about 140Mbit, but due
to some major optimizations by felix to fix a bunch of mis-alignment
issues. Through the router, I've seen 260Mbit - which is perilously
close to the speed that I can drive it at from the test boxes.

>
> Does perf/perf_events (whatever the followon to perfmon2 is called) have
> support for the CPU used in the device?  (Assuming it even has a PMU to be
> queried in the first place)

Yes. Don't think it's enabled. It is running flat out, according to top.

>
>> That said, I understand that people like their statistics, and me,
>> I'm trying to make split-tcp work better, ultimately, one day....
>>
>> I'm going to rerun this without the fw rules next.
>
> It would be interesting to see if the csum time goes away.  Long ago and far
> away when I was beating on a 32-core system with aggregate netperf TCP_RR
> and enabling or not FW rules, conntrack had a non-trivial effect indeed on
> performance.

Stays about the same. iptables time drops. How to disable conntrack?
Don't you only really
need it for nat?

>
> http://markmail.org/message/exjtzel7vq2ugt66#query:netdev%20conntrack%20rick%20jones%2032%20netperf+page:1+mid:s5v5kylvmlfrpb7a+state:results
>
> I think will get to the start of that thread.  The subject is '32 core
> net-next stack/netfilter "scaling"'
>
> rick jones
>



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

  parent reply	other threads:[~2011-08-31  1:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-31  0:32 Dave Taht
2011-08-31  1:01 ` Rick Jones
2011-08-31  1:10   ` Simon Barber
2011-08-31  1:20     ` Simon Barber
2011-08-31  1:45   ` Dave Taht [this message]
2011-08-31  1:58     ` Dave Taht
2011-08-31  3:28       ` Dave Taht
2011-08-31 16:19         ` Rick Jones
2011-08-31 15:55     ` Rick Jones
2011-08-31  1:41 ` Dave Taht

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='CAA93jw6vAZfLz=MUsxMnG0Ku1RPAn65FU5Z+sBh4UYyK0LY8ig@mail.gmail.com' \
    --to=dave.taht@gmail.com \
    --cc=bloat-devel@lists.bufferbloat.net \
    --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