Re: [PATCH v8 net-next 0/2] Explicit TSO segment count

["Kumar Kartikeya Dwivedi" <memxor@gmail.com>]

On Mon Aug 24, 2026 at 10:21 PM CEST, Chia-Yu Chang (Nokia) wrote:
>> -----Original Message-----
>> From: Kumar Kartikeya Dwivedi <memxor@gmail.com>
>> Sent: Monday, August 24, 2026 10:10 PM
>> To: Jakub Kicinski <kuba@kernel.org>; Chia-Yu Chang (Nokia) <chia-yu.chang@nokia-bell-labs.com>
>> Cc: john.fastabend@gmail.com; jakub@cloudflare.com; jiayuan.chen@linux.dev; netdev@vger.kernel.org; bpf@vger.kernel.org; ast@kernel.org; daniel@iogearbox.net; andrii@kernel.org; eddyz87@gmail.com; martin.lau@linux.dev; song@kernel.org; yonghong.song@linux.dev; jolsa@kernel.org; emil@etsalapatis.com; linux-kselftest@vger.kernel.org; shuah@kernel.org; horms@kernel.org; dsahern@kernel.org; pabeni@redhat.com; jhs@mojatatu.com; stephen@networkplumber.org; davem@davemloft.net; edumazet@google.com; andrew+netdev@lunn.ch; donald.hunter@gmail.com; kuniyu@google.com; ij@kernel.org; ncardwell@google.com; Koen De Schepper (Nokia) <koen.de_schepper@nokia-bell-labs.com>; g.white@cablelabs.com; ingemar.s.johansson@ericsson.com; mirja.kuehlewind@ericsson.com; cheshire@apple.com; rs.ietf@gmx.at; Jason_Livingood@comcast.com; vidhi_goel@apple.com; Mike_Rudolph@comcast.com; Jeff_Howe@comcast.com; srichard@netapp.com
>> Subject: Re: [PATCH v8 net-next 0/2] Explicit TSO segment count
>>
>>
>> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
>>
>>
>>
>> On Mon Aug 24, 2026 at 10:05 PM CEST, Jakub Kicinski wrote:
>> > On Mon, 24 Aug 2026 18:31:37 +0200 chia-yu.chang@nokia-bell-labs.com
>> > wrote:
>> >> From: Chia-Yu Chang <chia-yu.chang@nokia-bell-labs.com>
>> >>
>> >> Hello,
>> >>
>> >> This series replaces the existing min_tso_segs() congestion control
>> >> callback with a new tso_segs() callback that allows congestion
>> >> control algorithms to provide an explicit TSO segment count for each data burst.
>> >>
>> >> To support BPF congestion controls, the series also exposes
>> >> tcp_tso_autosize() as a BPF kfunc, allowing BPF implementations to
>> >> reuse the kernel TSO autosizing logic while implementing custom
>> >> tso_segs() callbacks.
>> >
>> > AI CI says:
>> >
>> > The bpf-ci build jobs are failing for this patch on all tested
>> > architectures/toolchains (x86-64 gcc-15, x86-64 llvm-21, aarch64
>> > gcc-15, s390x gcc-15), all with the same link-time error:
>> >
>> >   net/ipv4/tcp_bbr.o: in function `__BTF_ID__set8__tcp_bbr_check_kfunc_ids':
>> >   tcp_bbr.c:(.BTF_ids+0x...): undefined reference to `KF_DEPRECATED'
>> >
>> > This comes from the change to net/ipv4/tcp_bbr.c that marks the
>> > retained
>> > bbr_min_tso_segs() kfunc entry with the KF_DEPRECATED flag:
>> >
>> >   BTF_ID_FLAGS(func, bbr_min_tso_segs, KF_DEPRECATED)
>> >   BTF_ID_FLAGS(func, bbr_tso_segs)
>> >
>> > KF_DEPRECATED does not resolve to a usable symbol/flag in this tree,
>> > so the BTF id set for tcp_bbr fails to link into vmlinux on every
>> > architecture and toolchain -- it's a straight undefined-reference
>> > error, not a per-arch/per-config issue.
>> >
>> > Could you drop the KF_DEPRECATED flag (or use a flag that this kfunc
>> > infrastructure actually defines) on bbr_min_tso_segs, and re-verify
>> > that the kernel links cleanly? A local `make net/ipv4/tcp_bbr.o
>> > vmlinux` build (or the bpf-ci selftest build job) should reproduce this quickly.
>> >
>> > Full build log for reference:
>> >
>> >   ld.lld-21: error: undefined symbol: KF_DEPRECATED
>> >   >>> referenced by usercopy_64.c
>> >   >>>               vmlinux.o:(__BTF_ID__set8__tcp_bbr_check_kfunc_ids)
>>
>> I think Chia-Yu's AI is hallucinating, it was a proposed flag but not added yet...
>
> Hi Kumar and Kuba,
>
> I will drop it in the next version; however, this AI hallucination is from Sashiko's feedback I got:
>
> https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260814173034.749151-1-chia-yu.chang%40nokia-bell-labs.com
>
> BTW, any BPF-related flag is suggested to be added for graceful degradation?
>

We don't have anything yet, but I will add something this cycle and figure out
how this can be marked deprecated then.

> Thanks.
> Chia-Yu