Received: by 10.192.165.156 with SMTP id m28csp541955imm; Tue, 17 Apr 2018 14:57:14 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/6wOfoRnf+Lzx8p+7g53DH62riPJ7pHeaQouct3oWTSOgOCplGwtAj0QNMUTlL4xFgJaBw X-Received: by 2002:a17:902:6e8f:: with SMTP id v15-v6mr3660858plk.245.1524002234103; Tue, 17 Apr 2018 14:57:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524002234; cv=none; d=google.com; s=arc-20160816; b=EVDNzPa5hZ7oLwrkbLbghHeU2BlXrzsuCuNo9qQuJBg9XEBSxI52ELQ/Md66FonzdX PP3EgZ/KuX/Vme52Z3bbw629+tormrmtUOlzqu37Tb0cQdrG0ixkg2C0dyQtV7Q827Mp RnPzufyBAObcdoxq8ehgFdvVx4uWilsnZQjDNUgz7j96B08x9o1InGBy2iScT7jfyeMo EArNlHgYrPDkK36v4Xiuwm+hvh6/907iPc28cgXC3pN8WjIj8pGLG2D70p6ccJR2bmYT MYJiIfqxCI67aNKqSI4zOXb8V6eE5v41TBQFfphAXUJz3r+Eb1syKmJ2Tk5qOlbAsXYs tAzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=0O+NlX/Kvbt1oSvlmgiu3qsHBb5wmRj5Q8lxl0msHl0=; b=fH5z7YmbEqKCorswclyE2ViUTPD7vyZ/blFCl/SfiBwe3m1+m3thWTa0y5ypjTvYqz doCPed5HMGEt27ShF3VU1VgiC/uenQdjEFx4h0baDy0030ivGERkQcv/9nwz4tDJnntO boRrY5SbYXCsqfz9Ou3Fktt8Xn/UGcd7THHCTdxZQNMmKZBdN+pc2Aup22Z0lAqOnIe3 KGpB72lRXJ8glu0YB7TtuhwmFu1IlFkqpqziv5gV1RGEcbRIm99GvvYNoezPpkkaPuGY xWV2QOzv78HOwlg5MnU/3wjBBTKMfnm2idgx27Nbcfj7TQ2hftnzzcGgJsYC7FNghz5P A6KQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20120113 header.b=T7H76iPZ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c76si12585970pga.156.2018.04.17.14.56.59; Tue, 17 Apr 2018 14:57:14 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20120113 header.b=T7H76iPZ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753251AbeDQVzi (ORCPT + 99 others); Tue, 17 Apr 2018 17:55:38 -0400 Received: from mail-it0-f67.google.com ([209.85.214.67]:32863 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752655AbeDQVzg (ORCPT ); Tue, 17 Apr 2018 17:55:36 -0400 Received: by mail-it0-f67.google.com with SMTP id x144-v6so15950721itc.0; Tue, 17 Apr 2018 14:55:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0O+NlX/Kvbt1oSvlmgiu3qsHBb5wmRj5Q8lxl0msHl0=; b=T7H76iPZsPav5q/7PNC+c0HPJNpN45F6piu9bEBfcD4DT2l8+Xvs/qDwPXyFXzz5uv U01SORQF/0rh1A9ih8hOGFc0HSAnyc2Tv6RbmxxWthV3x2oMJDSvNJcihT8kVUjeUOrL cXtrcQo6w4Y46iyfShqnxFYwOJM1xeII2xUuSIr1rXORs7miMPwdGeGmI24ZON3HWxj9 A8NGLrywe24ciHHqbs/RpElJbBB3Lo+QajG7KMH606U6GdirLBm7njkZTlswGQVo+utQ ehZH/W38kd9r0G1AB5JZqtFK7TX4VA2Kb71st2iu0+B+h6EA9K+q7tXWvI48zhGakwib xD5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0O+NlX/Kvbt1oSvlmgiu3qsHBb5wmRj5Q8lxl0msHl0=; b=Xeun+ZMRDTXHuXJqvLznxJ7VOzTjZjIpcd0VbQwqADq76fSmO8l+nPoroFVZfKmRCK 9XSfNW5hTuC0GykRalct8qUUp+9hr7YeKLMrHZ8UYKSv1LwCbzR3wuCNQAfT2dcfFIJI +JWrwY0wRxSsLgwV+XP3yU2E3PWGNk/1jQnS7tZR0It8dho5GPNybVXCZ34LOjAZy/Ma gtKALeL7Wi95t5wzUdVAeDsnu/5trm7KJVWVzCQer1A4Qp4WBBTb9TTGaJVIMqndrynC E6X9YrCg2qNMlvhlAVYXsTfp2Qm8pBWEBc8NRqQLMyVff9WniVuZ1SJVgdaJyXD6U1Ct cG3g== X-Gm-Message-State: ALQs6tDgicXeYIgJuqT5XpzJ0B3EtDBDYZx9cb3i0qmPpQKX2OtcBzhG 3/E1XorjxUJ+OYx1mbQWZ1NOnAL0DVIIOK7hs1I= X-Received: by 2002:a24:d345:: with SMTP id n66-v6mr532635itg.0.1524002135923; Tue, 17 Apr 2018 14:55:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.181.10 with HTTP; Tue, 17 Apr 2018 14:54:55 -0700 (PDT) In-Reply-To: References: <1523983016-11005-1-git-send-email-laoar.shao@gmail.com> From: Yafang Shao Date: Wed, 18 Apr 2018 05:54:55 +0800 Message-ID: Subject: Re: [PATCH v2 net-next] net: introduce a new tracepoint for tcp_rcv_space_adjust To: Song Liu Cc: "eric.dumazet@gmail.com" , "davem@davemloft.net" , "kuznet@ms2.inr.ac.ru" , "yoshfuji@linux-ipv6.org" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 18, 2018 at 1:38 AM, Song Liu wrote: > > >> On Apr 17, 2018, at 9:36 AM, Yafang Shao wrote: >> >> tcp_rcv_space_adjust is called every time data is copied to user space, >> introducing a tcp tracepoint for which could show us when the packet is >> copied to user. >> This could help us figure out whether there's latency in user process. >> >> When a tcp packet arrives, tcp_rcv_established() will be called and with >> the existed tracepoint tcp_probe we could get the time when this packet >> arrives. >> Then this packet will be copied to user, and tcp_rcv_space_adjust will >> be called and with this new introduced tracepoint we could get the time >> when this packet is copied to user. >> >> arrives time : user process time => latency caused by user >> tcp_probe tcp_rcv_space_adjust >> >> Hence in the printk message, sk_cookie is printed as a key to relate >> tcp_rcv_space_adjust with tcp_probe. >> >> Maybe we could export sockfd in this new tracepoint as well, then we >> could relate this new tracepoint with epoll/read/recv* tracepoints, and >> finally that could show us the whole lifespan of this packet. But we >> could also implement that with pid as these functions are executed in >> process context. >> >> Signed-off-by: Yafang Shao >> >> --- >> v1 -> v2: use sk_cookie as key suggested by Eric. >> --- >> include/trace/events/tcp.h | 33 +++++++++++++++++++++++++++------ >> net/ipv4/tcp_input.c | 2 ++ >> 2 files changed, 29 insertions(+), 6 deletions(-) >> >> diff --git a/include/trace/events/tcp.h b/include/trace/events/tcp.h >> index 3dd6802..814f754 100644 >> --- a/include/trace/events/tcp.h >> +++ b/include/trace/events/tcp.h >> @@ -10,6 +10,7 @@ >> #include >> #include >> #include >> +#include >> >> #define TP_STORE_V4MAPPED(__entry, saddr, daddr) \ >> do { \ >> @@ -125,6 +126,7 @@ >> __array(__u8, daddr, 4) >> __array(__u8, saddr_v6, 16) >> __array(__u8, daddr_v6, 16) >> + __field(__u64, sock_cookie) >> ), >> >> TP_fast_assign( >> @@ -144,12 +146,24 @@ >> >> TP_STORE_ADDRS(__entry, inet->inet_saddr, inet->inet_daddr, >> sk->sk_v6_rcv_saddr, sk->sk_v6_daddr); >> + >> + /* >> + * sk_cookie is used to identify a socket, with which we could >> + * relate this tracepoint with other tracepoints, >> + * i.e. tcp_probe. >> + * If we needn't this relation, then sk_cookie is useless; >> + * if we need this relation, then tcp_probe is already set, >> + * and sk_cookie is already set in tcp_probe, so we could get >> + * the value directly. >> + */ >> + __entry->sock_cookie = atomic64_read(&sk->sk_cookie); >> ), >> >> - TP_printk("sport=%hu dport=%hu saddr=%pI4 daddr=%pI4 saddrv6=%pI6c daddrv6=%pI6c", >> + TP_printk("sport=%hu dport=%hu saddr=%pI4 daddr=%pI4 saddrv6=%pI6c daddrv6=%pI6c sock_cookie=%llu", >> __entry->sport, __entry->dport, >> __entry->saddr, __entry->daddr, >> - __entry->saddr_v6, __entry->daddr_v6) >> + __entry->saddr_v6, __entry->daddr_v6, >> + __entry->sock_cookie) >> ); >> >> DEFINE_EVENT(tcp_event_sk, tcp_receive_reset, >> @@ -166,6 +180,13 @@ >> TP_ARGS(sk) >> ); >> >> +DEFINE_EVENT(tcp_event_sk, tcp_rcv_space_adjust, >> + >> + TP_PROTO(const struct sock *sk), >> + >> + TP_ARGS(sk) >> +); >> + >> TRACE_EVENT(tcp_retransmit_synack, >> >> TP_PROTO(const struct sock *sk, const struct request_sock *req), >> @@ -232,6 +253,7 @@ >> __field(__u32, snd_wnd) >> __field(__u32, srtt) >> __field(__u32, rcv_wnd) >> + __field(__u64, sock_cookie) >> ), >> >> TP_fast_assign( >> @@ -256,15 +278,14 @@ >> __entry->rcv_wnd = tp->rcv_wnd; >> __entry->ssthresh = tcp_current_ssthresh(sk); >> __entry->srtt = tp->srtt_us >> 3; >> + __entry->sock_cookie = sock_gen_cookie(sk); >> ), >> >> - TP_printk("src=%pISpc dest=%pISpc mark=%#x length=%d snd_nxt=%#x " >> - "snd_una=%#x snd_cwnd=%u ssthresh=%u snd_wnd=%u srtt=%u " >> - "rcv_wnd=%u", >> + TP_printk("src=%pISpc dest=%pISpc mark=%#x length=%d snd_nxt=%#x snd_una=%#x snd_cwnd=%u ssthresh=%u snd_wnd=%u srtt=%u rcv_wnd=%u sock_cookie=%llu", >> __entry->saddr, __entry->daddr, __entry->mark, >> __entry->length, __entry->snd_nxt, __entry->snd_una, >> __entry->snd_cwnd, __entry->ssthresh, __entry->snd_wnd, >> - __entry->srtt, __entry->rcv_wnd) >> + __entry->srtt, __entry->rcv_wnd, __entry->sock_cookie) >> ); >> >> #endif /* _TRACE_TCP_H */ >> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c >> index f93687f..43ad468 100644 >> --- a/net/ipv4/tcp_input.c >> +++ b/net/ipv4/tcp_input.c >> @@ -582,6 +582,8 @@ void tcp_rcv_space_adjust(struct sock *sk) >> u32 copied; >> int time; >> >> + trace_tcp_rcv_space_adjust(sk); >> + >> tcp_mstamp_refresh(tp); >> time = tcp_stamp_us_delta(tp->tcp_mstamp, tp->rcvq_space.time); >> if (time < (tp->rcv_rtt_est.rtt_us >> 3) || tp->rcv_rtt_est.rtt_us == 0) >> -- >> 1.8.3.1 >> > > If I understand this correctly, you can get all the information you need with > a kprobe on tcp_rcv_space_adjust(). Why is it necessary to introduce a new > tracepoint? > Tracepoint is less expensive and more cnovinient, that is the same reason why tcp_probe.c was removed and tcp_probe tracepoint was introduced. Thanks Yafang