All of lore.kernel.org
 help / color / mirror / Atom feed
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);

  reply	other threads:[~2026-09-14  8:24 UTC|newest]

Thread overview: 12+ 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-14  8:14 ` [PATCH 0/2] Drop redundant tcp_rate_check_app_limited calls MPTCP CI
2026-09-15 23:01 ` 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 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.