From: Eric Dumazet <edumazet@google.com>
To: Jason Xing <kerneljasonxing@gmail.com>
Cc: mhiramat@kernel.org, mathieu.desnoyers@efficios.com,
rostedt@goodmis.org, kuba@kernel.org, pabeni@redhat.com,
davem@davemloft.net, netdev@vger.kernel.org,
linux-trace-kernel@vger.kernel.org,
Jason Xing <kernelxing@tencent.com>
Subject: Re: [PATCH net-next v3 3/3] tcp: add location into reset trace process
Date: Fri, 29 Mar 2024 10:13:02 +0100 [thread overview]
Message-ID: <CANn89iJw8x-LqgsWOeJQQvgVg6DnL5aBRLi10QN2WBdr+X4k=w@mail.gmail.com> (raw)
In-Reply-To: <20240329034243.7929-4-kerneljasonxing@gmail.com>
On Fri, Mar 29, 2024 at 4:43 AM Jason Xing <kerneljasonxing@gmail.com> wrote:
>
> From: Jason Xing <kernelxing@tencent.com>
>
> In addition to knowing the 4-tuple of the flow which generates RST,
> the reason why it does so is very important because we have some
> cases where the RST should be sent and have no clue which one
> exactly.
>
> Adding location of reset process can help us more, like what
> trace_kfree_skb does.
Well, I would prefer a drop_reason here, even if there is no 'dropped' packet.
This would be more stable than something based on function names that
could be changed.
tracepoints do not have to get ugly, we can easily get stack traces if needed.
perf record -a -g -e tcp:tcp_send_reset ...
next prev parent reply other threads:[~2024-03-29 9:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-29 3:42 [PATCH net-next v3 0/3] tcp: make trace of reset logic complete Jason Xing
2024-03-29 3:42 ` [PATCH net-next v3 1/3] trace: adjust TP_STORE_ADDR_PORTS_SKB() parameters Jason Xing
2024-03-29 8:49 ` Eric Dumazet
2024-03-29 3:42 ` [PATCH net-next v3 2/3] trace: tcp: fully support trace_tcp_send_reset Jason Xing
2024-03-29 9:07 ` Eric Dumazet
2024-03-29 10:22 ` Jason Xing
2024-03-29 10:43 ` Eric Dumazet
2024-03-29 3:42 ` [PATCH net-next v3 3/3] tcp: add location into reset trace process Jason Xing
2024-03-29 9:13 ` Eric Dumazet [this message]
2024-03-29 10:40 ` Jason Xing
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CANn89iJw8x-LqgsWOeJQQvgVg6DnL5aBRLi10QN2WBdr+X4k=w@mail.gmail.com' \
--to=edumazet@google.com \
--cc=davem@davemloft.net \
--cc=kerneljasonxing@gmail.com \
--cc=kernelxing@tencent.com \
--cc=kuba@kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.