Re: [PATCH net-next 00/10] tcp: support non-GSO jumbograms

[Mariusz Klimek <maklimek97@gmail.com>]

On 6/9/26 03:15, Eric Dumazet wrote:
> On Mon, Jun 8, 2026 at 9:35 AM Mariusz Klimek <maklimek97@gmail.com> wrote:
>>
>> This series adds support for sending TCP jumbograms over MTUs above 65535,
>> and adds support for setting such MTUs on veth devices.
>>
>> The TCP stack is already capable of receiving jumbograms and (up until
>> recently) sending GSO-jumbograms that get segmented before exiting the
>> host. However, the TCP stack doesn't support sending regular jumbograms
>> over high MTUs as described in RFC2675. Specifically, the TCP stack doesn't
>> support an MSS greater than 65535.
>>
>> No device currently supports setting an MTU greater than 65535 but there
>> are some devices that could benefit from higher MTUs and that can
>> theoretically support it. For example, IPoIB in connected-mode can support
>> MTUs up to 2^31. Virtual devices such as veth have no physical limitations
>> and therefore could also support such MTUs.
>>
>> This series only adds support for setting high MTUs on veth devices, with
>> support for other devices being delegated to future patch series. Allowing
>> jumbograms to pass through veth devices is useful for testing jumbogram
>> functionality, and also increases throughput when compared to BIG TCP (see
>> the benchmark numbers below).
>>
>> In addition to removing the upper limit on veth MTUs, This series adds the
>> missing pieces that allow the TCP stack to send TCP jumbograms. This
>> includes a bit of code removed recently by Alice's patch series [1]. Most
>> of the patches in this series are rather trivial. The main problem
>> addressed by this series is that the TCP stack conflates the TSO segment
>> length with the MSS, but the TSO segment length is a 16-bit integer, which
>> doesn't allow for MSS > 65535. This series decouples them.
>>
>> Running iperf over veth on an Intel Core i9-12900K CPU shows a 5%
>> improvement in throughput.
>>
>> Commands:
>> iperf3 -s
>> iperf3 -c -l 500KiB ${SERVER_IP}%veth0
> 
> You are adding code to TCP fast path, for a narrow (and possibly
> dangerous) use case.
> 
> I am sorry, I will not review this patch series coming from a first-timer.

I understand your concerns and they're reasonable. I would still like to
proceed with this series, though. What can I do for you to consider this
series? Would it help to submit a few less-significant patches first before
resubmitting this patch series? Should I resubmit it as an RFC?

This feature is opt-in, so even though I'm adding code to the TCP fastpath, it
should be relatively straightforward to check that it doesn't introduce any
bugs in the regular MTU < 65535 flow.

-- 
Mariusz K.