On 03/09/2013 01:26 AM, Rick Jones wrote: > >> >> 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. I didn't set the -D option to disable nagle. But I get almost the almost same result with -D (1024 byte TCP_STREAM from guest to local host). > > 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 majordomo@xxxxxxxxxxxxxxx >> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
