linux-kernel - Re: seeing strange values for tcp sk_rmem

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

Message-ID: <4B183059.4070109@nortel.com>
Date:	Thu, 03 Dec 2009 15:40:41 -0600
From:	"Chris Friesen" <cfriesen@...tel.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	netdev@...r.kernel.org, Linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: seeing strange values for tcp sk_rmem_alloc

On 12/03/2009 11:04 AM, Eric Dumazet wrote:
> Chris Friesen a écrit :

>> Ah, that makes a difference.  But the results (see below) still
>> look odd.  For this test, /proc/sys/net/core/rmem_default is
>> 118784.  For some reason sk_rmem_alloc gets bumped by 16KB when I
>> only send 2KB of data, and it drops back down again every 6
>> packets.

> 
> Might be because you use loopback device ? ;)
> 
> ifconfig lo | grep MTU UP LOOPBACK RUNNING  MTU:16436  Metric:1
> 
> After a while (when hitting rcvbuf limit), tcp stack performs skb
> collapses, to reduce ram usage.

Looks like this is indeed the case, changing the loopback mtu to 8K
makes it increase in 8K increments.  This is quite unexpected, since for
UDP it only increases by the actual amount of the data being sent rather
than the size of the full MTU.

As it stands, it looks like sk_rmem_alloc isn't very useful.  Can you
point me to something that is more reflective of the actual space used
by the tcp socket?  I'd like something that increases monotonically with
received data and once it exceeds the configured size then the tcp stack
will start dropping packets.  Does such a thing exist, or is the tcp
stack just too complicated to easily obtain this sort of information?

Thanks for your help,

Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/