All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rick Jones <rick.jones2@hp.com>
To: "David S. Miller" <davem@davemloft.net>
Cc: olof@lixom.net, andrew.grover@intel.com, netdev@vger.kernel.org
Subject: Re: [PATCH 0/10] [IOAT] I/OAT patches repost
Date: Thu, 20 Apr 2006 18:00:37 -0700	[thread overview]
Message-ID: <44482EB5.9030605@hp.com> (raw)
In-Reply-To: <20060420.172742.132879746.davem@davemloft.net>

> Unfortunately, many benchmarks just do raw bandwidth tests sending to
> a receiver that just doesn't even look at the data.  They just return
> from recvmsg() and loop back into it.  This is not what applications
> using networking actually do, so it's important to make sure we look
> intelligently at any benchmarks done and do not fall into the trap of
> saying "even without cache warming it made things faster" when in fact
> the tested receiver did not touch the data at all so was a false test.

FWIW, netperf can be configured to access the buffers it gives to send() 
or gets from recv().  A ./configure --enable-dirty in TOT:

http://www.netperf.org/svn/netperf2/trunk

will enable two global options:

  -k dirty,clean # bytes to dirty, bytes to read clean on netperf side

  -K dirty,clean # as above, on netserver side.

And in such a netperf the test banner will include the string "dirty 
data" (alas the default output will not say how much :)

In say a TCP_STREAM test -k will affect what is done with a buffer 
before send() is called, and -K will affect what is done with a buffer 
_before_ recv() is called with that buffer.

-k N will cause the first N bytes of the buffer to be dirtied, and the 
next N bytes to be read clean

-k N, will cause the first N bytes of the buffer to be dirtied

-k ,N will cause the first N bytes of the buffer to be read clean

-k M,N will cause the first M bytes to be dirtied, the next N bytes to 
be read clean

Actually, that brings-up a question - presently, and for reasons that 
are lost to me in the mists of time - netperf will "access" the buffer 
before it calls recv().  I'm wondering if that should be changed to an 
access of the buffer after it calls recv()?

And I suspect related to all this is whether or not one should alter the 
size of the buffer ring being used by netperf, which by default is the 
SO_*BUF size divided by the send_size (or recv_size) plus one buffers - 
the -W option can control that.

rick jones

  reply	other threads:[~2006-04-21  1:00 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-20 20:49 [PATCH 0/10] [IOAT] I/OAT patches repost Andrew Grover
2006-04-20 21:33 ` Olof Johansson
2006-04-20 22:14   ` Andrew Grover
2006-04-20 23:33     ` Olof Johansson
2006-04-21  0:44       ` David S. Miller
2006-04-21  3:09         ` Olof Johansson
2006-04-21  0:38     ` David S. Miller
2006-04-21  1:02       ` Rick Jones
2006-04-21  2:23       ` Herbert Xu
2006-04-21  0:27   ` David S. Miller
2006-04-21  1:00     ` Rick Jones [this message]
2006-04-21  1:13       ` David S. Miller
2006-04-21 17:12         ` Rick Jones
2006-04-27 23:49           ` Chris Leech
2006-04-27 23:53             ` Rick Jones
2006-04-21  3:04     ` Olof Johansson
2006-04-21  3:42       ` David S. Miller
2006-04-21  4:42         ` Olof Johansson
2006-04-27 23:45         ` Chris Leech
2006-04-21 17:13     ` Ingo Oeser

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=44482EB5.9030605@hp.com \
    --to=rick.jones2@hp.com \
    --cc=andrew.grover@intel.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=olof@lixom.net \
    /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.