From: sashiko-bot@kernel.org
To: chia-yu.chang@nokia-bell-labs.com
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH v7 net-next 1/2] tcp: Replace min_tso_segs() with tso_segs() CC callback
Date: Sat, 15 Aug 2026 17:31:00 +0000 [thread overview]
Message-ID: <20260815173100.AFE401F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260814173034.749151-2-chia-yu.chang@nokia-bell-labs.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] BPF API breakage: `tcp_tso_autosize` is not exposed as a BPF kfunc, making it impossible for custom BPF congestion control algorithms to correctly implement the new `tso_segs` callback.
--
--- Patch [1]: [PATCH v7 net-next 1/2] tcp: Replace min_tso_segs() with tso_segs() CC callback ---
commit c7a0bf37c3be2ea7dea45bba16c15ffe35b92e31
Author: Chia-Yu Chang <chia-yu.chang@nokia-bell-labs.com>
tcp: Replace min_tso_segs() with tso_segs() CC callback
This commit replaces the min_tso_segs() callback in TCP congestion control
with a new tso_segs() callback. It exports tcp_tso_autosize() for use by
loadable kernel modules and updates the CC algorithms to use the new callback.
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index fcaa04e65189b..7d3e0e715c4bf 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
[ ... ]
> @@ -2269,6 +2269,7 @@ static u32 tcp_tso_autosize(const struct sock *sk, unsigned int mss_now,
>
> return max_t(u32, bytes / mss_now, min_tso_segs);
> }
> +EXPORT_SYMBOL_GPL(tcp_tso_autosize);
[Severity: High]
Since the new tso_segs callback completely bypasses the core kernel's
tcp_tso_autosize() logic, BPF congestion control algorithms must now return
the absolute final TSO segment count instead of just a minimum bound.
Although this patch exports tcp_tso_autosize() for loadable kernel modules,
is there a reason it wasn't also registered as a BPF kfunc (via BTF_ID_FLAGS)
in the kfunc registry for BPF TCP congestion control?
Without being able to call tcp_tso_autosize() from BPF programs, custom BPF
struct_ops CC algorithms cannot easily compute the autosized value. If they
return a small constant to match the old API, they might inadvertently hardcap
TSO burst size and cause severe performance regressions. Otherwise, they are
forced to redundantly reimplement complex internal kernel state logic within
BPF.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260814173034.749151-1-chia-yu.chang@nokia-bell-labs.com?part=1
next prev parent reply other threads:[~2026-08-15 17:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-14 17:30 [PATCH v7 net-next 0/2] Explicit TSO segment count chia-yu.chang
2026-08-14 17:30 ` [PATCH v7 net-next 1/2] tcp: Replace min_tso_segs() with tso_segs() CC callback chia-yu.chang
2026-08-15 17:31 ` sashiko-bot [this message]
2026-08-14 17:30 ` [PATCH v7 net-next 2/2] bpf: make tcp_tso_autosize() available to BPF congestion controls chia-yu.chang
2026-08-15 17:31 ` sashiko-bot
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=20260815173100.AFE401F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=chia-yu.chang@nokia-bell-labs.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox