Hi Alexei,
>>You have to explain why Prague CC cannot rely on autosizing.
>>To me it sounds like a red flag. autosizing logic was there for a decade, if
>>not more.
>>And now you're arguing that your CC logic is special and it deserves new API
>>and breakage of existing convention.
>>Maybe you should step back and reconsider.
The objective behind Prague auto-sizing is that the TSO burst should not create
a queuing latency bigger than 250us, on a bottleneck link rate that is the
pacing rate. The rationale is that the L4S AQMs are allowed to have a very
small threshold (often somewhere between 0.5ms to 1ms). When the pacing rate is
96Mbps we start allowing TSO size of 2, etc... Below 96Mbps the TSO size is 1,
and below 48Mbps the potential serialization time of a single packet is bigger
than 250us. You will also see in other patches that we limit the serialization
time of one MTU to 10ms when the rate goes lower than 1Mbps by limiting the max
MTU (going down to a minimum pacing rate of 100kbps as the minimum sending
rate).
L4S AQMs are designed with these parameters in mind. As AQMs usually work
packet per packet and evaluate waiting time in the queue, definitely the
minimum inter-packet departure time needs to be bigger than the serialization
time - 0.5ms or packets will get marked without necessarily using the full link
capacity.
The current autosizing algo has as objective to scale the TSO size depending on
both pacing rate and RTT. It targets a 1ms queue delay burst when the RTT is
bigger than 3ms, but when the RTT is smaller it further increases the TSO-size.
The rationale behind this is that a bigger TSO-size results in a bigger chance
of loss, and that loss is easier to retransmit if the RTT is smaller.
So, the current algorithm does not line up with the Prague expectations. Is
allows bursts of 1ms instead of 250us and it allows even bigger bursts if the
minimum RTT is below 3ms (for instance 27ms burst at 10Mbps and 1ms RTT).
I see following options how to include the Prague requirement of 250us burst
instead of 1ms and not increasing TSO if the RTT is lower than 3ms:
- Let Prague do the calculation and set the desired TSO size
- previously done with an extra hook to overwrite the autosize, but it
was already commented to avoid the extra hook
- change the existing hook and add a fixed or max TSO size (current
patch did the fixed TSO overruling, maybe a max could be more general as it
would always be lower than the current calculated autosize)
- Add a cc settable parameter max-TSO-burst-time to let the current autosize do
the extra calculation and take this extra check into account
- we are open to any other suggestions...
Koen.
-----Original Message-----
From: Alexei Starovoitov <[email protected]>
Sent: Wednesday, July 1, 2026 7:56 AM
To: Chia-Yu Chang (Nokia) <[email protected]>;
[email protected]; [email protected]; [email protected];
[email protected]; [email protected]; [email protected];
[email protected]; [email protected]; [email protected]; [email protected];
[email protected]; [email protected]; [email protected]; [email protected];
[email protected]; [email protected]; [email protected]; [email protected];
[email protected]; [email protected]; [email protected];
[email protected]; [email protected]; [email protected];
[email protected]; [email protected]; Koen De Schepper (Nokia)
<[email protected]>; [email protected];
[email protected]; [email protected];
[email protected]; [email protected]; [email protected];
[email protected]
Subject: Re: [PATCH v3 net-next 1/1] tcp: Replace min_tso_segs() with
tso_segs() CC callback
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 Tue Jun 30, 2026 at 10:46 PM PDT, Chia-Yu Chang (Nokia) wrote:
>> > - /* override sysctl_tcp_min_tso_segs (optional) */
>> > - u32 (*min_tso_segs)(struct sock *sk);
>> > + /*
>> > + * Override tcp_tso_autosize (optional)
>> > + *
>> > + * If provided, this callback returns the final TSO segment number
>> > + * and will bypass tcp_tso_autosize() entirely. The implementation
>> > + * must derive an appropriate value and ensure the result is valid.
>> > + */
>> > + u32 (*tso_segs)(struct sock *sk, u32 mss_now);
>>
>> I don't like this interface change.
>> It introduces churn for no good reason.
>> At least I don't see why you cannot live with the existing api.
>
> Hi Alexei,
>
> This patch was part of TCP Prague preparation series:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> .kernel.org%2Fall%2F20260611161504.228319-4-chia-yu.chang%40nokia-bell
> -labs.com%2F&data=05%7C02%7Ckoen.de_schepper%40nokia-bell-labs.com%7C5
> a4af4e411b5485a2abb08ded735768f%7C5d4717519675428d917b70f44f9630b0%7C0
> %7C0%7C639184821777198173%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRy
> dWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%
> 3D%7C0%7C%7C%7C&sdata=yBTs89k8g2CSHfi0preWag0X%2BR%2F5vJAmRw6ijEK4E1k%
> 3D&reserved=0 Our original patch is to add an extra tso_segs, and
> after discussion it's recommended to replace exisiting min_tso_segs.
>
> This is needed because TCP Prague would set the exact TSO size rather than
> using autosizing from TCP.
> The TCP Prague itself is planned to be submitted after all preparation
> commits are accepted.
> You can find its current stauts:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2FL4STeam%2Flinux-net-next%2Fblob%2Fupstream_l4steam%2Fnet%2Fip
> v4%2Ftcp_prague.c&data=05%7C02%7Ckoen.de_schepper%40nokia-bell-labs.co
> m%7C5a4af4e411b5485a2abb08ded735768f%7C5d4717519675428d917b70f44f9630b
> 0%7C0%7C0%7C639184821777240736%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk
> iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf
> Q%3D%3D%7C0%7C%7C%7C&sdata=1tkkWXoSYqOyvr3FkmKpybDt2M6P7BOY240SEvkjfqY
> %3D&reserved=0
You have to explain why Prague CC cannot rely on autosizing.
To me it sounds like a red flag. autosizing logic was there for a decade, if
not more.
And now you're arguing that your CC logic is special and it deserves new API
and breakage of existing convention.
Maybe you should step back and reconsider.
