From: Jakub Kicinski <kuba@kernel.org>
To: Yan Zhai <yan@cloudflare.com>
Cc: Ivan Babrou <ivan@cloudflare.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-team@cloudflare.com, Eric Dumazet <edumazet@google.com>,
"David S. Miller" <davem@davemloft.net>,
Paolo Abeni <pabeni@redhat.com>,
Steven Rostedt <rostedt@goodmis.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
David Ahern <dsahern@kernel.org>
Subject: Re: [RFC PATCH net-next] tcp: add a tracepoint for tcp_listen_queue_drop
Date: Wed, 12 Jul 2023 10:42:10 -0700 [thread overview]
Message-ID: <20230712104210.3b86b779@kernel.org> (raw)
In-Reply-To: <CAO3-PbrZHn1syvhb3V57oeXigE_roiHCbzYz5Mi4wiymogTg2A@mail.gmail.com>
On Wed, 12 Jul 2023 11:42:26 -0500 Yan Zhai wrote:
> The issue with kfree_skb is not that it fires too frequently (not in
> the 6.x kernel now). Rather, it is unable to locate the socket info
> when a SYN is dropped due to the accept queue being full. The sk is
> stolen upon inet lookup, e.g. in tcp_v4_rcv. This makes it unable to
> tell in kfree_skb which socket a SYN skb is targeting (when TPROXY or
> socket lookup are used). A tracepoint with sk information will be more
> useful to monitor accurately which service/socket is involved.
No doubt that kfree_skb isn't going to solve all our needs, but I'd
really like you to clean up the unnecessary callers on your systems
first, before adding further tracepoints. That way we'll have a clear
picture of which points can be solved by kfree_skb and where we need
further work.
next prev parent reply other threads:[~2023-07-12 17:42 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-11 4:34 [RFC PATCH net-next] tcp: add a tracepoint for tcp_listen_queue_drop Ivan Babrou
2023-07-12 2:36 ` Jakub Kicinski
2023-07-12 16:42 ` Yan Zhai
2023-07-12 17:42 ` Jakub Kicinski [this message]
2023-07-13 2:43 ` Yan Zhai
2023-07-13 16:57 ` Jakub Kicinski
2023-07-13 23:17 ` Ivan Babrou
2023-07-14 3:14 ` Jakub Kicinski
2023-07-14 23:21 ` Ivan Babrou
2023-07-18 21:57 ` Jakub Kicinski
2023-07-18 22:11 ` Ivan Babrou
2023-07-14 15:09 ` David Ahern
2023-07-14 23:38 ` Ivan Babrou
2023-07-15 1:30 ` David Ahern
2023-07-18 22:10 ` Ivan Babrou
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=20230712104210.3b86b779@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=ivan@cloudflare.com \
--cc=kernel-team@cloudflare.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rostedt@goodmis.org \
--cc=yan@cloudflare.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).