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
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
