All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Fink <billfink@mindspring.com>
To: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Cc: 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: Wed, 9 Jul 2008 22:50:35 -0400	[thread overview]
Message-ID: <20080709225035.a4d39cb5.billfink@mindspring.com> (raw)
In-Reply-To: <20080709183432.GB5383@2ka.mipt.ru>

On Wed, 9 Jul 2008, Evgeniy Polyakov wrote:

> On Wed, Jul 09, 2008 at 11:10:31AM -0700, Roland Dreier (rdreier@cisco.com) wrote:
> > so somehow setting the window helps with the scheduling of
> > processes... I guess autotuning lets some queue get too long or
> > something like that.  The actual window doesn't matter too much, since
> > the delay of the network is low enough that even though the bandwidth is
> > very high, the BDP is quite small.  (With a 25 usec RTT, a 128 KB window
> > should be enough for 40 Gbps, well over the raw link speed of 16 Gbps
> > that I have)
> 
> That may be cache issues: depending on what application does it can be
> useful or not to be bound to the same CPU. I suppose if benchmark looks
> into the packet content, then it likely wants to be on the same CPU to
> aliminate cache line ping-pongs, otherwise it only needs to be awakened
> to send/receive next chunk, so having it on different CPU may result in
> better its utilization...

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.

I wonder if the "-w128" forces the socket buffer to a small enough size
that it totally fits in cache and this helps the performance.

						-Bill

  reply	other threads:[~2008-07-10  2:50 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                   ` Bill Fink [this message]
2008-07-10 17:26                     ` setsockopt() Rick Jones
2008-07-11  0:50                       ` setsockopt() Bill Fink
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=20080709225035.a4d39cb5.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=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.