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: Thu, 13 Jul 2023 09:57:47 -0700 [thread overview]
Message-ID: <20230713095747.580c2b0a@kernel.org> (raw)
In-Reply-To: <CAO3-PbqtdX+xioiQfOCxVovKVYUgXkrmsfw+1wTYoJiAq=2=ng@mail.gmail.com>
On Wed, 12 Jul 2023 21:43:32 -0500 Yan Zhai wrote:
> Those are not unnecessary calls, e.g. a lot of those kfree_skb come
> from iptables drops, tcp validation, ttl expires, etc. On a moderately
> loaded server, it is called at a rate of ~10k/sec, which isn't
> terribly awful given that we absorb millions of attack packets at each
> data center. We used to have many consume skb noises at this trace
> point with older versions of kernels, but those have gone ever since
> the better separation between consume and drop.
I was hoping you can break them down by category.
Specifically what I'm wondering is whether we should also have
a separation between policy / "firewall drops" and error / exception
drops. Within the skb drop reason codes, I mean.
next prev parent reply other threads:[~2023-07-13 16:58 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
2023-07-13 2:43 ` Yan Zhai
2023-07-13 16:57 ` Jakub Kicinski [this message]
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=20230713095747.580c2b0a@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 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.