Message-ID: <AANLkTikyoS-YDH+N92yCXiFg7MfXhSHeudND9VJgAp15@mail.gmail.com>
Date:	Sun, 20 Mar 2011 00:30:58 -0700
From:	Jerry Chu <hkchu@...gle.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Stephen Hemminger <shemminger@...tta.com>, netdev@...r.kernel.org
Subject: Re: [PATCH] Add useful per-connection TCP stats for diagnosis purpose.

On Fri, Mar 18, 2011 at 11:03 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
>
> Le vendredi 18 mars 2011 à 22:38 -0700, Jerry Chu a écrit :
> > On Fri, Mar 18, 2011 at 10:02 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> > > Le vendredi 18 mars 2011 à 21:33 -0700, Jerry Chu a écrit :
> > >
> > >> I'm well aware of the past, hideous O(n**2) problem of reading
> > >> /proc/net/tcp but I
> > >> thought the problem has been fixed by Tom Herbert a while back, no?
> > >> (See http://marc.info/?l=linux-netdev&m=127588123429437&w=2)
> > >>
> > >
> > > O(N) is still too slow, to gather stats for your socket, if you want to
> > > gather stats once per second for example.
> >
> > I don't see anyway around O(n). The netlink/inet_diag_dump() will take at
> > best O(n) too.
>
> 1) netlink is extensible, without breaking old apps.
>
> 2) netlink is able to dump part of the information, while
> whith /proc/net/tcp you have to cat all the file and grep the needed
> info. O(1) is better than O(10)
>
> Example :
>
> I only want info of socket identified by dst ip 192.168.0.144 and dst
> port 58196
>
> # ss -emoi dst 192.168.20.144:58196
> State       Recv-Q Send-Q     Local Address:Port         Peer Address:Port
> ESTAB       0      0         192.168.20.108:65111      192.168.20.144:58196    ino:3302 sk:ffff88011c278c80
>         mem:(r0,w0,f0,t0) sack cubic wscale:7,7 rto:201 rtt:1.75/0.75 cwnd:10 send 66.7Mbps rcv_space:14600
>
> I want all sockets to remote 192.168.20.110
> # ss -emoi dst 192.168.20.110
> State       Recv-Q Send-Q     Local Address:Port         Peer Address:Port
> ESTAB       0      0      ::ffff:192.168.20.108:ssh     ::ffff:192.168.20.110:47633    timer:(keepalive,120min,0) ino:70342 sk:ffff88011c381500
>         mem:(r0,w0,f0,t0) ts sack ecn cubic wscale:8,7 rto:207 rtt:7.625/11.5 ato:40 cwnd:10 send 15.2Mbps rcv_rtt:1 rcv_space:14480

I presume the filtering of specific IP addrs/ports are done in the
kernel to short-circuit the
O(n) loop. Otherwise it seems moot (i.e., it still costs O(n)).

A quick look at inet_csk_diag_dump() does not reveal anything like
that. But I haven't
looked hard enough.

>
>
> 3) getsockopt(fd) is O(1)
>
> >
> > >
> > > AFAIK, I am not sure we want to allow any user to access all these data
> > > for all tcp sockets on the machine. This might have security impacts.
> >
> > This seems to be an orthogonal issue to netlink or /proc/net/tcp.
>
> getsockopt(fd) only finds information about your own socket.

Make no mistake if my usage case was driven by specific apps why would I
waste my time chasing /proc/net/tcp? In fact we've had a private
TCP_INFO_EXT socket option for years used by some specific apps. (We
have not tried to pushed it upstreams because some of the counters we collect
are too Google specific.)

But my immediate use of the counters/stats proposed here is for our internal
monitor programs to take samples occasionally from ALL CONNECTIONS, or for
diagnosis purpose from the TCP layer when we don't have specific info about the
apps' IP or port# (so we just want to dump info from all connections).

>
> An application might want to log tcp information only right before
> closing one socket. This sounds more practical than having a separate
> spy thread.

I'm not trying to use /proc/net/tcp (or netlink) because I don't know about
other, more efficient way to retrieve counters from a subset, or even just one
specific connection as explained above.

Jerry

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

Powered by blists - more mailing lists