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:	Tue, 8 Jul 2008 08:54:43 +0400
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	David Miller <davem@...emloft.net>
Cc:	aglo@...i.umich.edu, shemminger@...tta.com, netdev@...r.kernel.org,
	rees@...ch.edu, bfields@...ldses.org
Subject: Re: setsockopt()

Hi.

On Mon, Jul 07, 2008 at 02:49:12PM -0700, David Miller (davem@...emloft.net) wrote:
> There is no reason these days to ever explicitly set the socket
> buffer sizes on TCP sockets under Linux.
> 
> If something is going wrong it's a bug and we should fix it.

Just for the reference: autosizing is (was?) not always working correctly
for some workloads at least couple of years ago.
For example I worked with small enough embedded systems with 16-32 MB
of RAM where socket buffer size never grew up more than 200Kb (100mbit
network), but workload was very bursty, so if remote system froze for
several milliseconds (and sometimes upto couple of seconds), socket
buffer was completely filled with new burst of data and either sending
started to sleep or returned EAGAIN, which resulted in semi-realtime
data to be dropped.

Setting buffer size explicitely to large enough value like 8Mb fixed
this burst issues. Another fix was to allocate data each time it becomes
ready and copy portion to this buffer, but allocation was quite slow,
which led to unneded latencies, which again could lead to data loss.

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