Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

Thanks for the patch! Let's try to converge with the upstream tcp_tso_autosize():
https://elixir.bootlin.com/linux/v6.10/source/net/ipv4/tcp_output.c#L2013

The motivation here: we will likely ultimately just switch BBR to using that. So instead of this patch, can you please change the declaration of the "bytes" variable from:

 u64 bytes;

to:

 unsigned long bytes;

I imagine that will fix it? If so, let's go with that.

Thanks!

@nealcardwell
updated.
tested build ok for mips.

This change addresses a build failure on 32-bit systems due to undefined division symbols:

arm:
ERROR: modpost: "__aeabi_uldivmod" [net/ipv4/tcp_bbr.ko] undefined!
ERROR: modpost: "__aeabi_ldivmod" [net/ipv4/tcp_bbr.ko] undefined!

x86, mips, ppc:
ERROR: modpost: "__udivdi3" [net/ipv4/tcp_bbr.ko] undefined!
ERROR: modpost: "__divdi3" [net/ipv4/tcp_bbr.ko] undefined!

Since `sk->sk_pacing_rate` is already an `unsigned long`, the `bytes` variable is
updated to `unsigned long` to resolve these division issues and ensure compatibility
across both 32-bit and 64-bit platforms.

Hi. I just noticed this is proposing to add this commit to bbr-v3-upstream-prep-2024-02-19-01. Any reason you are proposing to use that branch instead of v3?

Hi. I just noticed this is proposing to add this commit to bbr-v3-upstream-prep-2024-02-19-01. Any reason you are proposing to use that branch instead of v3?

I happened to use the bbr-v3-upstream-prep-2024-02-19-01 branch, but there’s no specific reason for it. You can easily cherry-pick this commit onto the v3 branch, or would you prefer me to submit a new PR directly to v3?