Re: [PATCH v5 mptcp-next 00/10] mptcp: introduce backlog processing

[Mat Martineau <martineau@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3030 bytes --]

On Fri, 17 Oct 2025, Geliang Tang wrote:

> Hi Paolo, Matt, Mat,
>
> On Wed, 2025-10-15 at 11:00 +0200, Paolo Abeni wrote:
>> On 10/13/25 11:07 AM, Geliang Tang wrote:
>>> On Fri, 2025-10-10 at 20:22 +0800, Geliang Tang wrote:
>>>> Hi Paolo,
>>>>
>>>> On Fri, 2025-10-10 at 10:21 +0200, Paolo Abeni wrote:
>>>>> On 10/9/25 3:58 PM, Paolo Abeni wrote:
>>>>>> @Geliang: if you reproduce the issue multiple times, are
>>>>>> there
>>>>>> any
>>>>>> common patterns ? i.e. sender files considerably larger than
>>>>>> the
>>>>>> client
>>>>>> one, or only a specific subsets of all the test-cases
>>>>>> failing, or
>>>>>> ...
>>>>>
>>>>> Other questions:
>>>>> - Can you please share your setup details (VM vs baremetal,
>>>>> debug
>>>>> config
>>>>> vs non debug, vmg vs plain qemu, number of [v]cores...)? I
>>>>> can't
>>>>> repro
>>>>> the issue locally.
>>>>
>>>> Here are my modifications:
>>>>
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/geliang/mptcp_net-next.git/log/?h=splice_new
>>>>
>>>> I used mptcp-upstream-virtme-docker normal config to reproduce
>>>> it:
>>>>
>>>> docker run \
>>>> 	-e INPUT_NO_BLOCK=1 \
>>>> 	-e INPUT_PACKETDRILL_NO_SYNC=1 \
>>>> 	-v "${PWD}:${PWD}:rw" -w "${PWD}" --privileged --rm -it
>>>> \
>>>>         --pull always ghcr.io/multipath-tcp/mptcp-upstream-
>>>> virtme-
>>>> docker:latest \
>>>> 	auto-normal
>>>>
>>>> $ cat .virtme-exec-run
>>>> run_loop run_selftest_one ./mptcp_connect_splice.sh
>>>>
>>>> Running mptcp_connect_splice.sh in a loop dozens of times should
>>>> reproduce the test failure.
>>>>
>>>>> - Can you please share a pcap capture _and_ the selftest text
>>>>> output
>>>>> for
>>>>> the same failing  test?
>>>
>>> The pcap captures (gQQ13x-ns1-ns3-MPTCP-MPTCP-dead:beef:3::2-10013-
>>> connector.pcap, gQQ13x-ns1-ns3-MPTCP-MPTCP-dead:beef:3::2-10013-
>>> listener.pcap) and the selftest text output (selftest_output) are
>>> attached.
>>
>> Looks like the 'stuck' scenario is quite consistent. The receiver
>> filled
>> it's receive window, and sent an ack shortly after when re-opening,
>> but
>> the sender did not react to such ack.
>>
>> The perf instrumentation I mentioned would be very useful. I tried to
>> capture it myself, but so far I failed - the repro run for several
>> hundred iterations without issues and finally podmad stuck (podman
>> bug
>> apparently, or local resources exhausted).
>>
>> Did you have better luck collecting the perf trace?
>
> Sorry, I haven't made any progress yet. Please give me some more time.
>
>
> I was thinking, since this issue only occurs during the splice test,
> let's move the discussion to the future "implement mptcp read_sock and
> splice" series. We shouldn't let it block the merging of this current
> series.
>
> I don't have any further constructive review comments on patches 9 and
> 10. I'm wondering if we should get input from Matt and Mat.
>

I am planning to take a close look at 9 & 10 early next week, would like 
to understand the new backlog rx path. Sorry for the delay!

- Mat