Well, the point is : if your app does write(1024) bytes, thats probably because it wants small packets from the very beginning. (See the TCP PUSH flag ?)
I think that raises the question of whether or not Jason was setting the test-specific -D option on his TCP_STREAM tests, to have netperf make a setsockopt(TCP_NODELAY) call.
happy benchmarking, rick jones
If the transport is slow, TCP stack will automatically collapse several write into single skbs (assuming TSO or GSO is on), and you'll see big GSO packets with tcpdump [1]. So TCP will help you to get less overhead in this case. But if transport is fast, you'll see small packets, and thats good for latency. So my opinion is : its exactly behaving as expected. If you want bigger packets either : - Make the application doing big write() - Slow the vmexit ;) [1] GSO fools tcpdump : Actual packets sent to the wire are not 'big packets', but they hit dev_hard_start_xmit() as GSO packets. -- 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
-- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
