netdev - Re: setsockopt()

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 9 Jul 2008 10:03:41 +0400
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Bill Fink <billfink@...dspring.com>
Cc:	Stephen Hemminger <stephen.hemminger@...tta.com>,
	Roland Dreier <rdreier@...co.com>,
	David Miller <davem@...emloft.net>, aglo@...i.umich.edu,
	shemminger@...tta.com, netdev@...r.kernel.org, rees@...ch.edu,
	bfields@...ldses.org
Subject: Re: setsockopt()

On Wed, Jul 09, 2008 at 01:47:58AM -0400, Bill Fink (billfink@...dspring.com) wrote:
> Are you sure you're not thinking about tcp_mem, which is a function
> of available memory, or has this been changed in more recent kernels?
> The 2.6.22.9 Documentation/networking/ip-sysctl.txt indicates:

In 2.6.25 tcp_mem depends on amount of ram, and third tcp_wmem is
calculated based on it:

/* Set per-socket limits to no more than 1/128 the pressure threshold */
limit = ((unsigned long)sysctl_tcp_mem[1]) << (PAGE_SHIFT - 7);
max_share = min(4UL*1024*1024, limit);

sysctl_tcp_wmem[0] = SK_MEM_QUANTUM;
sysctl_tcp_wmem[1] = 16*1024;
sysctl_tcp_wmem[2] = max(64*1024, max_share);

sysctl_tcp_rmem[0] = SK_MEM_QUANTUM;
sysctl_tcp_rmem[1] = 87380;
sysctl_tcp_rmem[2] = max(87380, max_share);

> tcp_wmem - vector of 3 INTEGERs: min, default, max
> 	...
> 	max: Maximal amount of memory allowed for automatically selected
> 	send buffers for TCP socket. This value does not override
> 	net.core.wmem_max, "static" selection via SO_SNDBUF does not use this.
> 	Default: 128K

Yeah, its a bit confusing. It probably was copypasted, there is no
default, but minimum possible value.

> 
> The TCP autotuning worked great, with both tests basically achieving
> full 10-GigE line rate.  The test with the TCP autotuning actually
> did slightly better than the test where an explicitly specified 1 MB
> socket buffer was used, although this could just be within the margin
> of error of the testing.

If you will check tcp_wmem on your machine, it will likely show that
tcp_wmem[max] is far larger than 128k. It is equal to 1mb on my old
laptop with 256mb of ram, I suppose machines equipped with 10gige
network adapters usually have slightly more.

-- 
	Evgeniy Polyakov
--
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