Jon Mason wrote:
The benefit of TSO is not throughput, but CPU utilization. Throughput
increase is usually a side effect because of better PCI DMA behavior (eg.
large PCI transfers are better).
I'm not looking for a throughput increase, the systems involved are already
capable of link-rate without TSO, just looking for throughput to not drop with
TSO. If it were a throughput drop because the NIC CPU (bletch) saturated that
would be one thing (such as happened with Tigon2 in another context) but this
drop stems from what appears to be not filling cwnd and getting acks delayed by
a timer.
Are you seeing a CPU utilization decrease?
Yes, at the cost of occasional pauses in the data stream.
TSO is on
TCP STREAM TEST to 192.168.13.1
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. 10^6bits/s % S % U us/KB us/KB
131072 262142 262142 10.00 843.86 12.77 -1.00 2.480 -1.000
TSO is off
TCP STREAM TEST to 192.168.13.1
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. 10^6bits/s % S % U us/KB us/KB
131072 262142 262142 10.00 941.13 22.82 -1.00 3.972 -1.000
This is with tcp_tso_win_divisor set to 1 so TSO kicks-in before 200some-oddK
are transfered. The service demand drop (modulo the accuracy of CPU util
measurements via the -DUSE_PROC_STAT stuff) is rather nice.
rick jones
subscribed, so mail to netdev will reach me - no need for separate cc
|