• A
    [DCCP]: Introduce dccp_get_info · 2babe1f6
    Arnaldo Carvalho de Melo 提交于
    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: NArnaldo Carvalho de Melo <acme@mandriva.com>
    Signed-off-by: NDavid S. Miller <davem@davemloft.net>
    2babe1f6
ccid3.c 58.3 KB