[DCCP]: Introduce dccp_get_info
authorArnaldo Carvalho de Melo <acme@mandriva.com>
Wed, 24 Aug 2005 04:52:35 +0000 (21:52 -0700)
committerDavid S. Miller <davem@sunset.davemloft.net>
Mon, 29 Aug 2005 23:05:07 +0000 (16:05 -0700)
commit2babe1f6fea717c36c008c878fe095d1ca5696c1
treef2ce23b6e5898a6bec8726f17104074516559397
parent4fded33b3e8177d1d2eec0ccc69af8dfe8b4c3c3
[DCCP]: Introduce dccp_get_info

And also hc_tx and hc_rx get_info functions for the CCIDs to fill in
information that is specific to them.

For now reusing struct tcp_info, later I'll try to figure out a better
solution, for now its really nice to get this kind of info:

[root@qemu ~]# ./ss -danemi
State       Recv-Q Send-Q  Local Addr:Port  Peer Addr:Port
LISTEN      0      0                *:5001          *:*     ino:628 sk:c1340040
         mem:(r0,w0,f0,t0) cwnd:0 ssthresh:0
ESTAB       0      0       172.20.0.2:5001 172.20.0.1:32785 ino:629 sk:c13409a0
         mem:(r0,w0,f0,t0) ts rto:1000 rtt:0.004/0 cwnd:0 ssthresh:0 rcv_rtt:61.377

This, for instance, shows that we're not congestion controlling ACKs,
as the above output is in the ttcp receiving host, and ttcp is a one
way app, i.e. the received never calls sendmsg, so
ccid_hc_tx_send_packet is never called, so the TX half connection
stays in TFRC_SSTATE_NO_SENT state and hctx_rtt is never calculated,
stays with the value set in ccid3_hc_tx_init, 4us, as show above in
milliseconds (0.004ms), upcoming patches will fix this.

rcv_rtt seems sane tho, matching ping results :-)

Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
net/dccp/ccid.h
net/dccp/ccids/ccid3.c
net/dccp/diag.c