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

[Geliang Tang <geliang@kernel.org>]

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.

Thanks,
-Geliang

> 
> /P
> 
>