| 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: <00e801cf3497$c37255f0$4a5701d0$@codeaurora.org> Date: Fri, 28 Feb 2014 08:14:22 -0700 From: "Harout Hedeshian" <harouth@...eaurora.org> To: <davem@...emloft.net> Cc: <netdev@...r.kernel.org> Subject: TCP: Support configurable delayed-ack parameters Hello David, I found a thread from June 2012 (subject matches this email) discussing the addition of parameters to manually tune the delayed TCP ACK parameters, and add new TCP socket options for application specific tuning. The patch in question would multiply the receive mss by some constant exposed in /proc. We have experimented with a similar approach and found significant improvements in performance when asymmetric links are utilized; specifically where the hardware is limited in egress packets/sec (but not raw bandwidth). As an example, in one test we saw a 100% improvement when doing rcv_mss*4. You had responded to the original patch by stating that you are fundamentally opposed to the feature. I'm trying to understand specifically what your objections are. Checking tcp_measure_rcv_mss() current implementation(as of 3.10), I do not see any way for rcv_mss to grow beyond the largest received skb length. Thanks, Harout -- Harout Hedeshian Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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