From: sashiko-bot@kernel.org
To: "Kuniyuki Iwashima" <kuniyu@google.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH v5 bpf-next 04/10] bpf: tcp: Guard fast-path bpf_tcp_ops_call() under per-socket flag.
Date: Thu, 08 Oct 2026 03:33:23 +0000 [thread overview]
Message-ID: <sashiko-outbox-163559@kernel.org> (raw)
In-Reply-To: <20261008031604.256498-5-kuniyu@google.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] tcp: stale saw_unknown flag partially defeats bpf_tcp_ops optimization
--
commit f118f1505af0dead6c4ecc71acf79379acbf604a
Author: Kuniyuki Iwashima <kuniyu@google.com>
bpf: tcp: Guard fast-path bpf_tcp_ops_call() under per-socket flag.
bpf_tcp_ops.{parse_hdr,hdr_opt_len} are called for every
incoming / outgoing skb.
bpf_tcp_ops.rtt is called once per RTT, which is every
incoming skb in ping-pong workloads like tcp_rr.
Even attaching NULL callbacks in the fast path hurts performance.
Let's guard them (and write_hdr_opt) with the new per-socket flags.
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index 209db8effcc41..4478d3f3d4b02 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
[ ... ]
> @@ -217,7 +222,12 @@ static void bpf_tcp_ops_parse_hdr(struct sock *sk, struct sk_buff *skb)
> return;
> }
>
> - bpf_tcp_ops_call(parse_hdr, sk, skb);
> + tp = tcp_sk(sk);
> +
> + if ((tp->rx_opt.saw_unknown &&
> + BPF_TCP_OPS_TEST_FLAG(tp, PARSE_HDR_OPT_UNKNOWN)) ||
> + BPF_TCP_OPS_TEST_FLAG(tp, PARSE_HDR_OPT_ALL))
> + __bpf_tcp_ops_call(parse_hdr, sk, skb);
> }
[Severity: Low]
Does this optimization rely on tp->rx_opt.saw_unknown being correctly cleared
for packets without unknown options?
Looking at tcp_fast_parse_options(), the fast parse path clears other option
state flags but fails to clear saw_unknown:
net/ipv4/tcp_input.c:tcp_fast_parse_options() {
if (th->doff == (sizeof(*th) / 4)) {
tp->rx_opt.saw_tstamp = 0;
tp->rx_opt.accecn = 0;
return false;
}
...
}
If a previous packet had an unknown option and set saw_unknown, could
subsequent packets that take the fast parse path retain the stale saw_unknown
value, causing the BPF program to be invoked spuriously and partially
defeating this optimization?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261008031604.256498-1-kuniyu@google.com?part=4
next prev parent reply other threads:[~2026-10-08 3:33 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-08 3:15 [PATCH v5 bpf-next 00/10] bpf: Add bpf_tcp_ops hooks for TCP AutoLOWAT Kuniyuki Iwashima
2026-10-08 3:15 ` [PATCH v5 bpf-next 01/10] bpf: tcp: Convert deny-list for bpf_{get,set}sockopt() to allow-list Kuniyuki Iwashima
2026-10-08 3:15 ` [PATCH v5 bpf-next 02/10] bpf: tcp: Add a new per-socket flag and kfunc for bpf_tcp_ops Kuniyuki Iwashima
2026-10-08 3:15 ` [PATCH v5 bpf-next 03/10] selftest: bpf: Use bpf_tcp_ops_set_flags() in bpf_tcp_ops_hdr.c Kuniyuki Iwashima
2026-10-08 3:15 ` [PATCH v5 bpf-next 04/10] bpf: tcp: Guard fast-path bpf_tcp_ops_call() under per-socket flag Kuniyuki Iwashima
2026-10-08 3:33 ` sashiko-bot [this message]
2026-10-08 4:02 ` bot+bpf-ci
2026-10-08 22:11 ` Stanislav Fomichev
2026-10-08 3:15 ` [PATCH v5 bpf-next 05/10] bpf: tcp: Check BPF_SOCK_OPS_TEST_FLAG() after cgroup_bpf_enabled(CGROUP_SOCK_OPS) Kuniyuki Iwashima
2026-10-08 16:56 ` Amery Hung
2026-10-08 22:11 ` Stanislav Fomichev
2026-10-08 3:15 ` [PATCH v5 bpf-next 06/10] bpf: tcp: Introduce bpf_tcp_ops.{enqueue,dequeue}_rcvq() Kuniyuki Iwashima
2026-10-08 3:15 ` [PATCH v5 bpf-next 07/10] tcp: Split out __tcp_set_rcvlowat() Kuniyuki Iwashima
2026-10-08 3:15 ` [PATCH v5 bpf-next 08/10] bpf: mptcp: Don't support BPF_TCP_OPS_FLAG_RCVQ Kuniyuki Iwashima
2026-10-08 3:15 ` [PATCH v5 bpf-next 09/10] bpf: tcp: Add kfunc to adjust sk->sk_rcvlowat Kuniyuki Iwashima
2026-10-08 3:43 ` sashiko-bot
2026-10-08 3:15 ` [PATCH v5 bpf-next 10/10] selftest: bpf: Add test for bpf_tcp_ops.{enqueue,dequeue}_rcvq() Kuniyuki Iwashima
2026-10-08 17:16 ` Amery Hung
2026-10-10 16:40 ` [PATCH v5 bpf-next 00/10] bpf: Add bpf_tcp_ops hooks for TCP AutoLOWAT patchwork-bot+netdevbpf
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=sashiko-outbox-163559@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=kuniyu@google.com \
--cc=sashiko-reviews@lists.linux.dev \
/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.