From: Bill Fink <billfink@mindspring.com>
To: Rick Jones <rick.jones2@hp.com>
Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru>,
Roland Dreier <rdreier@cisco.com>,
David Miller <davem@davemloft.net>,
aglo@citi.umich.edu, shemminger@vyatta.com,
netdev@vger.kernel.org, rees@umich.edu, bfields@fieldses.org
Subject: Re: setsockopt()
Date: Thu, 10 Jul 2008 20:50:45 -0400 [thread overview]
Message-ID: <20080710205045.8b8a0eee.billfink@mindspring.com> (raw)
In-Reply-To: <48764629.6090209@hp.com>
On Thu, 10 Jul 2008, Rick Jones wrote:
> > In my own network benchmarking experience, I've generally gotten the
> > best performance results when the nuttcp application and the NIC
> > interrupts are on the same CPU, which I understood was because of
> > cache effects.
>
> Interestingly enough I have a slightly different experience:
>
> *) single-transaction, single-stream TCP_RR - best when app and NIC use
> same core
>
> *) bulk transfer - either TCP_STREAM or aggregate TCP_RR:
> a) enough CPU on one core to reach max tput, best when same core
> b) not enough, tput max when app and NIC on separate cores,
> preferably cores sharing some cache
>
> That is in the context of either maximizing throughput or minimizing
> latency. If the context is most efficient transfer, then in all cases
> my experience thusfar agrees with yours.
Yes, I was talking about single stream bulk data transfers, where the
CPU was not a limiting factor (just barely when doing full 10-GigE
line rate transfers with 9000-byte jumbo frames).
On multiple stream tests there can be a benefit to spreading the load
across multiple cores.
-Bill
next prev parent reply other threads:[~2008-07-11 0:51 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-07 18:18 setsockopt() Olga Kornievskaia
2008-07-07 21:24 ` setsockopt() Stephen Hemminger
2008-07-07 21:30 ` setsockopt() Olga Kornievskaia
2008-07-07 21:33 ` setsockopt() Stephen Hemminger
2008-07-07 21:49 ` setsockopt() David Miller
2008-07-08 4:54 ` setsockopt() Evgeniy Polyakov
2008-07-08 6:02 ` setsockopt() Bill Fink
2008-07-08 6:29 ` setsockopt() Roland Dreier
2008-07-08 6:43 ` setsockopt() Evgeniy Polyakov
2008-07-08 7:03 ` setsockopt() Roland Dreier
2008-07-08 18:48 ` setsockopt() Bill Fink
2008-07-09 18:10 ` setsockopt() Roland Dreier
2008-07-09 18:34 ` setsockopt() Evgeniy Polyakov
2008-07-10 2:50 ` setsockopt() Bill Fink
2008-07-10 17:26 ` setsockopt() Rick Jones
2008-07-11 0:50 ` Bill Fink [this message]
2008-07-08 20:48 ` setsockopt() Stephen Hemminger
2008-07-08 22:05 ` setsockopt() Bill Fink
2008-07-09 5:25 ` setsockopt() Evgeniy Polyakov
2008-07-09 5:47 ` setsockopt() Bill Fink
2008-07-09 6:03 ` setsockopt() Evgeniy Polyakov
2008-07-09 18:11 ` setsockopt() J. Bruce Fields
2008-07-09 18:43 ` setsockopt() Evgeniy Polyakov
2008-07-09 22:28 ` setsockopt() J. Bruce Fields
2008-07-10 1:06 ` setsockopt() Evgeniy Polyakov
2008-07-10 20:05 ` [PATCH] Documentation: clarify tcp_{r,w}mem sysctl docs J. Bruce Fields
2008-07-10 23:50 ` David Miller
2008-07-08 20:12 ` setsockopt() Jim Rees
2008-07-08 21:54 ` setsockopt() John Heffner
2008-07-08 23:51 ` setsockopt() Jim Rees
2008-07-09 0:07 ` setsockopt() John Heffner
2008-07-07 22:50 ` setsockopt() Rick Jones
2008-07-07 23:00 ` setsockopt() David Miller
2008-07-07 23:27 ` setsockopt() Rick Jones
2008-07-08 1:15 ` setsockopt() Rick Jones
2008-07-08 1:48 ` setsockopt() J. Bruce Fields
2008-07-08 1:44 ` setsockopt() David Miller
2008-07-08 3:33 ` setsockopt() John Heffner
2008-07-08 18:16 ` setsockopt() Rick Jones
2008-07-08 19:10 ` setsockopt() John Heffner
[not found] ` <349f35ee0807090255s58fd040bne265ee117d06d397@mail.gmail.com>
2008-07-09 10:38 ` setsockopt() Jerry Chu
2008-07-07 21:32 ` setsockopt() J. Bruce Fields
2008-07-08 1:17 ` setsockopt() John Heffner
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=20080710205045.8b8a0eee.billfink@mindspring.com \
--to=billfink@mindspring.com \
--cc=aglo@citi.umich.edu \
--cc=bfields@fieldses.org \
--cc=davem@davemloft.net \
--cc=johnpol@2ka.mipt.ru \
--cc=netdev@vger.kernel.org \
--cc=rdreier@cisco.com \
--cc=rees@umich.edu \
--cc=rick.jones2@hp.com \
--cc=shemminger@vyatta.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.