netdev - Re: [PATCH] net: export the number of times the recv queue was full

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]

Message-Id: <20091210.134807.54217873.davem@davemloft.net>
Date:	Thu, 10 Dec 2009 13:48:07 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	rick.jones2@...com
Cc:	eparis@...hat.com, netdev@...r.kernel.org
Subject: Re: [PATCH] net: export the number of times the recv queue was full

From: Rick Jones <rick.jones2@...com>
Date: Thu, 10 Dec 2009 13:38:41 -0800

> Eric Paris wrote:
>> We got a request in which a customer was trying to determine how often
>> their
>> recieve queue was full and thus they were sending a zero window back
>> to the
>> other side.  By the time they would notice the slowdowns they would
>> have all
>> empty receive queues and wouldn't know which socket was a problem. 
> 
> Wouldn't a tcpdump command with suitable filter expression on the
> window field of the TCP header do?
> 
>> It also
>> allows them to find the sockets in which they need to up the recv
>> queue size
>> rather than doing it for all sockets across the box. 
> 
> Doesn't Linux by default "autotune" the socket buffers? (Or perhaps is
> that how they got zero windows from time to time anyway?)

The window will "autotune" only if the connection is not application
limited.

Their applications, therefore, by definition are getting filled up
receive queues because it is busy doing something other than reading
from the socket when data arrives (disk I/Os, etc.)
--
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