We have -Z for the sender. We should have it for the receiver too.

There is some nice sample code here:

http://blog.superpat.com/2010/06/01/zero-copy-in-linux-with-sendfile-and-splice/

fixed. closing

Did we fix this? I don't think so. We do have some receiver-side performance improvements, but not involving splice().

I assumed that was the fix you committed today, since the CPU went down some much.

(OK, I should have actually looked at the change log! )

So I guess not. I'll reopen it.

closed in error. Reopening

By the way, splice() is not a guaranteed win because it takes two splice() calls to replace the previous single read() call. No bytes get moved but still, extra syscall. Have to benchmark it carefully.

Is it not possible to increase server receive performance by:

• only reading the first few bytes from the socket (ie containing the per packet iperf proto info) & 'skipping' the rest by advancing the fd read pointer ...reduces CPU & memory resources especially for large packets

&

• repeated reads of the socket to clear any back-log of received packets before running the timer/scheduler routine; helps especially for small packet test cases.

&

• provide some instructions on how the user can increase the amount of buffering available to the kernel/NIC card driver (means the CPU can be away from iperf receive for longer before drops due to no buffering occur).

NOTE: profiling the server code with 'perf' indicates ~25 - 30% of the cycles are spent in memcpy; next highest item is @ ~5% (some piece of kernel code, not specific iperf code).

Grab this.