Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Skip to content
Commit 2babe1f6 authored by Arnaldo Carvalho de Melo's avatar Arnaldo Carvalho de Melo Committed by David S. Miller
Browse files

[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: default avatarArnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
parent 4fded33b
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment