Re: [PATCH 0/10] [IOAT] I/OAT patches repost

[Rick Jones <rick.jones2@hp.com>]

David S. Miller wrote:
> From: "Andrew Grover" <andy.grover@gmail.com>
> 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