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]

Date:	Thu, 10 Dec 2009 16:52:27 -0500
From:	Eric Paris <eparis@...hat.com>
To:	Rick Jones <rick.jones2@...com>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH] net: export the number of times the recv queue was full

On Thu, 2009-12-10 at 13:38 -0800, Rick Jones wrote:
> 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 could as a post processing measure be used to find this situation.  I
believe they want a more 'on the fly' method.

> > 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?)
> 
> Or does this customer's application(s) bypass that by making explicit 
> setsockopt() calls, and presumably have a way to tell the application(s) on a 
> destination by destination basis which connections to increase?

I believe their intent is to explicitly set the size larger for the
sockets they learn that their application needs it for and smaller for
those it knows it doesn't.

> More generically, zero window means the application isn't calling read/recv fast 
> enough right?  Or is it "known" that the traffic the applcation is receiving is 
> bursty and this isn't a sustained overload situation?

My understanding it that that is correct, it is not a sustained load
situation so looking at the rx-queue after the fact is useless for
discovering where they are getting overloaded.

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