David S. Miller wrote:
From: "Andrew Grover" <[EMAIL PROTECTED]>
Date: Thu, 20 Apr 2006 15:14:15 -0700
First obviously it's a technology for RX CPU improvement so there's no
benefit on TX workloads. Second it depends on there being buffers to
copy the data into *before* the data arrives. This happens to be the
case for benchmarks like netperf and Chariot, but real apps using
poll/select wouldn't see a benefit, Just laying the cards out here.
BUT we are seeing very good CPU savings on some workloads, so for
those apps (and if select/poll apps could make use of a
yet-to-be-implemented async net interface) it would be a win.
I don't know what the breakdown is of apps doing blocking reads vs.
waiting, does anyone know?
All the bandwidth benchmarks tend to block, real world servers (and
most clients to some extent) tend to use non-blocking reads and
poll/select except in some very limited cases and designs doing
something like 1 thread per connection.
Another netperf2 option :) (not exported via configure though) if a
certain define is set - look at recv_tcp_stream() in nettest_bsd.c -
then netperf will call select() before it calls recv().
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
