netdev - TCP: Support configurable delayed-ack parameters

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

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