lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <1392066100.6615.55.camel@edumazet-glaptop2.roam.corp.google.com> Date: Mon, 10 Feb 2014 13:01:40 -0800 From: Eric Dumazet <eric.dumazet@...il.com> To: Thomas Glanzmann <thomas@...nzmann.de> Cc: "Nicholas A. Bellinger" <nab@...ux-iscsi.org>, John Ogness <john.ogness@...utronix.de>, Eric Dumazet <edumazet@...gle.com>, "David S. Miller" <davem@...emloft.net>, target-devel <target-devel@...r.kernel.org>, Linux Network Development <netdev@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org> Subject: Re: [PATCH] This extends tx_data and and iscsit_do_tx_data with the additional parameter flags and avoids sending multiple TCP packets in iscsit_fe_sendpage_sg On Mon, 2014-02-10 at 21:56 +0100, Thomas Glanzmann wrote: > Hello Nab, > > > 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. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists