From: Geliang Tang <tanggeliang@kylinos.cn>

Increase the sendfile count by one to ensure the transmission size
exceeds the actual data length. This triggers the splice_eof path
in the kernel, allowing the newly implemented MPTCP splice_eof
interface to be exercised during testing.

The change from 'count' to 'count + 1' forces the sendfile operation
to attempt sending one more byte than available, which activates the
end-of-file handling in the splicing logic and ensures coverage of
the related MPTCP code paths.

Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
---
 tools/testing/selftests/net/mptcp/mptcp_connect.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/net/mptcp/mptcp_connect.c b/tools/testing/selftests/net/mptcp/mptcp_connect.c
index cbe573c4ab3a..2aaf3ed11315 100644
--- a/tools/testing/selftests/net/mptcp/mptcp_connect.c
+++ b/tools/testing/selftests/net/mptcp/mptcp_connect.c
@@ -870,7 +870,7 @@ static int do_sendfile(int infd, int outfd, unsigned int count,
 	while (count > 0) {
 		ssize_t r;
 
-		r = sendfile(outfd, infd, NULL, count);
+		r = sendfile(outfd, infd, NULL, count + 1);
 		if (r < 0) {
 			perror("sendfile");
 			return 3;
-- 
2.51.0

Hi Geliang,

On 02/02/2026 10:21, Geliang Tang wrote:
> From: Geliang Tang <tanggeliang@kylinos.cn>
> 
> Increase the sendfile count by one to ensure the transmission size
> exceeds the actual data length. This triggers the splice_eof path
> in the kernel, allowing the newly implemented MPTCP splice_eof
> interface to be exercised during testing.
> 
> The change from 'count' to 'count + 1' forces the sendfile operation
> to attempt sending one more byte than available, which activates the
> end-of-file handling in the splicing logic and ensures coverage of
> the related MPTCP code paths.

I'm a bit confused: is this splice_eof interface not linked to "splice"?
Why is it used with sendfile()?

Also, what's the behaviour without the implementation of "splice_eof()"?
Was it a wrong behaviour or is it the same? What's the differences
between the situation before and after this series?

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.

Hi Matt,

On Mon, 2026-02-02 at 11:09 +0100, Matthieu Baerts wrote:
> Hi Geliang,
> 
> On 02/02/2026 10:21, Geliang Tang wrote:
> > From: Geliang Tang <tanggeliang@kylinos.cn>
> > 
> > Increase the sendfile count by one to ensure the transmission size
> > exceeds the actual data length. This triggers the splice_eof path
> > in the kernel, allowing the newly implemented MPTCP splice_eof
> > interface to be exercised during testing.
> > 
> > The change from 'count' to 'count + 1' forces the sendfile
> > operation
> > to attempt sending one more byte than available, which activates
> > the
> > end-of-file handling in the splicing logic and ensures coverage of
> > the related MPTCP code paths.
> 
> I'm a bit confused: is this splice_eof interface not linked to
> "splice"?
> Why is it used with sendfile()?

.splice_eof hook is indeed triggered by sendfile(), not by splice().

sendfile -> do_sendfile -> do_splice_direct -> do_splice_direct_actor
-> splice_direct_to_actor -> do_splice_eof.

> 
> Also, what's the behaviour without the implementation of
> "splice_eof()"?
> Was it a wrong behaviour or is it the same? What's the differences
> between the situation before and after this series?

Without 'splice_eof', it was no a wrong behaviour, but MPTCP didn't
previously handle the splice EOF notification. TCP handled it.

> 
> Cheers,
> Matt