On Mon, 2014-02-10 at 21:56 +0100, Thomas Glanzmann wrote:
Hello Nab,
quoted
This looks correct to me. Thomas, once your able to confirm please
include your 'Tested-by' and I'll include for the next -rc3 PULL
request.
Eric is currently reviewing our latest iteration with MSG_MORE for
kernel_sendmsg and MSG_MORE | MSG_SENDPAGE_NOTLAST for sendpage. However
with the last iteration we had again a high RTT for some packets. But
than Eric let me tune net.ipv4.tcp_min_tso_segs to 8 and the RTT went
down to what it used before auto corking was enabled. At least almost.
Hmm.. I was not aware of high RTT for some packets.
Can you spot this on the pcap you provided ?
I'm having a steep learning curve but Eric hopefully knows how to get
this back in check. Nevertheless the regression I saw are history
because I saw that Eric has submitted the patch to David S. Miller which
fixes the two bugs that killed the iSCSI performance when tcp auto
corking was on. So currently we're just optimizing to get the last 20%
or so out of it. Quite interesting. Especially how much bandwidth can be
saved by coalescing packets.
It depends on the ratio payload/headers.
The beginning of your pcap show a lot of 512 bytes requests, so for this
kind of requests, the gain is huge (maybe 50%), but for 32K or 64K
request, gain would be marginal.