From: Jiayuan Chen <jiayuan.chen@linux.dev>
To: Geliang Tang <geliang@kernel.org>,
John Fastabend <john.fastabend@gmail.com>,
Jakub Sitnicki <jakub@cloudflare.com>,
Eric Dumazet <edumazet@google.com>,
Neal Cardwell <ncardwell@google.com>,
Kuniyuki Iwashima <kuniyu@google.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Sabrina Dubroca <sd@queasysnail.net>,
David Howells <dhowells@redhat.com>,
Matthieu Baerts <matttbe@kernel.org>,
Mat Martineau <martineau@kernel.org>
Cc: Geliang Tang <tanggeliang@kylinos.cn>,
netdev@vger.kernel.org, bpf@vger.kernel.org,
mptcp@lists.linux.dev
Subject: Re: [PATCH bpf 1/2] bpf: drop duplicate check_app_limited in tcp_bpf_push
Date: Mon, 14 Sep 2026 16:24:22 +0800 [thread overview]
Message-ID: <da26d2f3-7283-4e9f-85b4-6c12b9beda99@linux.dev> (raw)
In-Reply-To: <f12f1d886c8ff2b6f6e48f797ccc861037eda685.1789368148.git.tanggeliang@kylinos.cn>
On 9/14/26 3:14 PM, Geliang Tang wrote:
> From: Geliang Tang <tanggeliang@kylinos.cn>
>
> When the sendpage->MSG_SPLICE_PAGES migration series replaced
> do_tcp_sendpages() with direct tcp_sendmsg_locked() calls, callers that
> had used do_tcp_sendpages() kept an explicit tcp_rate_check_app_limited(sk)
> that was originally needed to cover do_tcp_sendpages() (which did not call
> tcp_rate_check_app_limited()). After the inlining, tcp_sendmsg_locked()
> always provides the check, and the outer call became redundant.
>
> The site changed here, tcp_bpf_push(), is a MSG_SPLICE_PAGES loop that
> holds the socket lock and only iterates when size > 0; tcp_sendmsg_locked()
> is invoked on every iteration with state identical to what the outer call
> sees, so dropping the outer call is safe and behavior-preserving.
>
> A potential benefit of this change is that it facilitates future reuse of
> tcp_bpf_push() for sockmap support in protocols beyond TCP, such as MPTCP.
> Since tcp_rate_check_app_limited() is TCP-specific while sendmsg_locked()
> is a generic interface in struct proto_ops, this change allows us to switch
> to different protocols via sk->sk_socket->ops->sendmsg_locked() without
> carrying protocol-specific assumptions.
>
> Fixes: ebf2e8860eea ("tcp_bpf: Inline do_tcp_sendpages as it's now a wrapper around tcp_sendmsg")
Same as the tls one: this looks like a cleanup to me. Is there a real
regression that affects kernel or user behavior?
Do we really need a Fixes tag?
> Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
> ---
> net/ipv4/tcp_bpf.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/net/ipv4/tcp_bpf.c b/net/ipv4/tcp_bpf.c
> index 2e234d155b5e..d5fcf3ce4861 100644
> --- a/net/ipv4/tcp_bpf.c
> +++ b/net/ipv4/tcp_bpf.c
> @@ -108,7 +108,6 @@ static int tcp_bpf_push(struct sock *sk, struct sk_msg *msg, u32 apply_bytes,
> off = sge->offset;
> page = sg_page(sge);
>
> - tcp_rate_check_app_limited(sk);
> retry:
> msghdr.msg_flags = flags | MSG_SPLICE_PAGES;
> has_tx_ulp = tls_sw_has_ctx_tx(sk);
next prev parent reply other threads:[~2026-09-14 8:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-14 7:14 [PATCH 0/2] Drop redundant tcp_rate_check_app_limited calls Geliang Tang
2026-09-14 7:14 ` [PATCH bpf 1/2] bpf: drop duplicate check_app_limited in tcp_bpf_push Geliang Tang
2026-09-14 8:24 ` Jiayuan Chen [this message]
2026-09-14 8:45 ` gang.yan
2026-09-14 9:31 ` Matthieu Baerts
2026-09-14 8:45 ` gang.yan
2026-09-14 10:06 ` Geliang Tang
2026-09-14 7:14 ` [PATCH net 2/2] tls: drop duplicate check_app_limited in tls_push_sg Geliang Tang
2026-09-14 8:07 ` bot+bpf-ci
2026-09-15 23:01 ` [PATCH 0/2] Drop redundant tcp_rate_check_app_limited calls Jakub Kicinski
2026-09-16 10:30 ` Geliang Tang
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=da26d2f3-7283-4e9f-85b4-6c12b9beda99@linux.dev \
--to=jiayuan.chen@linux.dev \
--cc=bpf@vger.kernel.org \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=edumazet@google.com \
--cc=geliang@kernel.org \
--cc=horms@kernel.org \
--cc=jakub@cloudflare.com \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=martineau@kernel.org \
--cc=matttbe@kernel.org \
--cc=mptcp@lists.linux.dev \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sd@queasysnail.net \
--cc=tanggeliang@kylinos.cn \
/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