why does tcp_v[46]_conn_request not inc MIB stats
Subsystems (2)
I've been digging around to see about inducing /proc/net/tcp to show some "interesting" things for listen sockets (eg backlog depth, its max, and dropped connection requests). While there I've noticed that both tcp_v[46]_syn_recv_sock and tcp_v[46]conn_request both check that the listen queue is full, but only tcp_v[46]_syn_recv_sock increments some mib stats for dropped connection requests.
Is that deliberate, or is that a hole in the stats?
rick jones
Quoted 3 lines · Rick Jones
I've been digging around to see about inducing
/proc/net/tcpto show some "interesting" things for listen sockets (eg backlog depth, its max, and dropped connection requests).
backlog depth(acceptq length) for a listening socket should be available with the newer kernels. The following patch exports this value via the rx_queue field in /proc/net/tcp.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=47da8ee681d04e68ca1b1812c10e28162150d453
Quoted 6 lines
While there I've noticed that both
tcp_v[46]_syn_recv_sock and tcp_v[46]conn_request both check that the listen queue is full, but only tcp_v[46]_syn_recv_sock increments some mib stats for dropped connection requests.Is that deliberate, or is that a hole in the stats?
looks like it is a hole in the stats. I think we should increment LISTENOVERFLOWS or LISTENDROPS in tcp_v[46]_conn_request too if the SYN is dropped.
Thanks
Sridhar
Quoted 9 lines · Sridhar Samudrala
Quoted 1 line · Rick Jones
I've been digging around to see about inducing
/proc/net/tcpto show some "interesting" things for listen sockets (eg backlog depth, its max, and dropped connection requests).backlog depth(acceptq length) for a listening socket should be available with the newer kernels. The following patch exports this value via the
rx_queuefield in/proc/net/tcp.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=47da8ee681d04e68ca1b1812c10e28162150d453
Yep, I see it in the 2.6.23-rc5 tree I'm using. At the risk of yet another "merely practice" patching excercise I'm putting together a patch which will also return that in a TCP_INFO and add the max backlog (to the tx_queue field)
While doing that, I've noticed that Documenation/networking/proc-net-tcp.txt (?) talks about a tcp6_get_info which I cannot find anywhere in the tree. I'm not sure if that simply means that tcp_get_info is what is used for a "tcp6" connection and the text can simply be removed from the documentation, or if it is called something else.
Quoted 9 lines
Quoted 4 lines
While there I've noticed that both
tcp_v[46]_syn_recv_sock and tcp_v[46]conn_request both check that the listen queue is full, but only tcp_v[46]_syn_recv_sock increments some mib stats for dropped connection requests.Is that deliberate, or is that a hole in the stats?
looks like it is a hole in the stats. I think we should increment LISTENOVERFLOWS or LISTENDROPS in tcp_v[46]_conn_request too if the SYN is dropped.
OK. Now, can we get a third to Sridhar's second?-)
rick jones
struggling through the maze of twisty routines for connection establishment
David Miller
maintainerFrom: Sridhar Samudrala <[email protected]>
Date: Mon, 10 Sep 2007 14:54:43 -0700
Quoted 3 lines
looks like it is a hole in the stats. I think we should increment LISTENOVERFLOWS or LISTENDROPS in tcp_v[46]_conn_request too if the SYN is dropped.
No we should not.
This is limiting embryonic mini-socket creation. The listen overflow should only increment when the 3-way handshake completion is aborted because the listening socket limit is exceeded, which is entirely different from the embryonic limit.
Quoted 4 lines · David Miller
This is limiting embryonic mini-socket creation. The listen overflow should only increment when the 3-way handshake completion is aborted because the listening socket limit is exceeded, which is entirely different from the embryonic limit.
That's true, but I think Rick has a point in that there should be some sort of (different) counter counting this. In general I believe every point in the stack who drops a packet should have a statistics counter so that it can be later diagnosed.
Rick, the best way to get such a counter in is to just send a patch, don't ask for it.
-Andi
Quoted 9 lines · Andi Kleen
Quoted 4 lines · David Miller
This is limiting embryonic mini-socket creation. The listen overflow should only increment when the 3-way handshake completion is aborted because the listening socket limit is exceeded, which is entirely different from the embryonic limit.
Quoted 6 lines
That's true, but I think Rick has a point in that there should be some sort of (different) counter counting this. In general I believe every point in the stack who drops a packet should
have a statistics counter so that it can be later diagnosed.Rick, the best way to get such a counter in is to just send a patch, don't ask for it.
I will try to work something up after cleaning-up the other listenq patch to remove the /proc/net/tcp[6] stuff, and an iproute2 patch I have to allow setting rto_min, rtt and rttvar using tc-esque units.
rick jones
David Miller
maintainerFrom: Rick Jones <[email protected]>
Date: Mon, 10 Sep 2007 11:42:18 -0700
Quoted 6 lines
I've been digging around to see about inducing
/proc/net/tcpto show some "interesting" things for listen sockets (eg backlog depth, its max, and dropped connection requests). While there I've noticed that both tcp_v[46]_syn_recv_sock and tcp_v[46]conn_request both check that the listen queue is full, but only tcp_v[46]_syn_recv_sock increments some mib stats for dropped connection requests.
They are checking two different things.
tcp_v{4,6}_conn_request is checking whether we are hitting the limit for allowing the initial SYN and creating a new embryonic mini-socket. Exceeding that is not a listen overflow.
tcp_v{4,6}_syn_recv_sock() is processing the end of the 3-way handshake and wants to create a full established state socket to queue into the listening parent. This is checking the listening socket queue limits, and indeed is a listen queue overflow if exceeded.
Quoted 4 lines · David Miller
From: Rick Jones <[email protected]>
Date: Mon, 10 Sep 2007 11:42:18 -0700
Quoted 8 lines
Quoted 1 line
I've been digging around to see about inducing
/proc/net/tcpto show some "interesting" things for listen sockets (eg backlog depth, its max, and dropped connection requests). While there I've noticed that both tcp_v[46]_syn_recv_sock and tcp_v[46]conn_request both check that the listen queue is full, but only tcp_v[46]_syn_recv_sock increments some mib stats for dropped connection requests.They are checking two different things.
tcp_v{4,6}_conn_request is checking whether we are hitting the limit for allowing the initial SYN and creating a new embryonic mini-socket. Exceeding that is not a listen overflow.
I'll risk some toe chewing and ask - is the embryonic limit set based on
what one sets in the listen() call and/or system configs?
Seems that _some_ sort of stat should be incremented, even if it isn't the listen queue overflow one?
rick jones
Quoted 4 lines
tcp_v{4,6}_syn_recv_sock() is processing the end of the 3-way handshake and wants to create a full established state socket to queue into the listening parent. This is checking the listening socket queue limits, and indeed is a listen queue overflow if exceeded.
David Miller
maintainerI'm rebasing a 500 patch tree which has tons of merge conflicts today, so I lack the time to answer your question.
Suffice it to say you could do a little bit of legwork to figure out the answer by researching inet_csk_reqsk_queue_is_full() and determining what sets the state tested by that function.
But you typically don't do this, you always push the queries back instead of figuring it out yourself, and that doesn't scale.
It can't be all me folks, people have to be as self-sufficient as possible in order for the work to be distributed properly.