November 6, 2025 at 24:28, "Matthieu Baerts" <matttbe@kernel.org mailto:matttbe@kernel.org?to=%22Matthieu%20Baerts%22%20%3Cmatttbe%40kernel.org%3E > wrote:
On 05/11/2025 17:12, Jiayuan Chen wrote:
November 5, 2025 at 22:40, "Matthieu Baerts" <matttbe@kernel.org mailto:matttbe@kernel.org?to=%22Matthieu%20Baerts%22%20%3Cmatttbe%40kernel.org%3E > wrote:
Hi Jiayuan,
Thank you for this new test!
I'm not very familiar with the BPF selftests: it would be nice if someone else can have a quick look.
Thanks for the review. I've seen the feedback on the other patches(1/3, 2/3) and will fix them up.
Thanks!
On 05/11/2025 12:36, Jiayuan Chen wrote:
Add test cases to verify that when MPTCP falls back to plain TCP sockets, they can properly work with sockmap. Additionally, add test cases to ensure that sockmap correctly rejects MPTCP sockets as expected. Signed-off-by: Jiayuan Chen jiayuan.chen@linux.dev
.../testing/selftests/bpf/prog_tests/mptcp.c | 150 ++++++++++++++++++ .../selftests/bpf/progs/mptcp_sockmap.c | 43 +++++ 2 files changed, 193 insertions(+) create mode 100644 tools/testing/selftests/bpf/progs/mptcp_sockmap.c diff --git a/tools/testing/selftests/bpf/prog_tests/mptcp.c b/tools/testing/selftests/bpf/prog_tests/mptcp.c index f8eb7f9d4fd2..56c556f603cc 100644 --- a/tools/testing/selftests/bpf/prog_tests/mptcp.c +++ b/tools/testing/selftests/bpf/prog_tests/mptcp.c @@ -6,11 +6,14 @@ #include <netinet/in.h> #include <test_progs.h> #include <unistd.h> +#include <error.h>
Do you use this new include?
"EOPNOTSUPP" I used was defined in error.h.
Ah OK. I usually only include 'error.h' to use 'error()'. Is it not 'errno.h' (or 'linux/errno.h') you want instead?
I'm just surprised it is not already included but another one above. But OK if it is not.
Okay, I'll look into it and see if I can get rid of the error.h header.
So here, the client is connected, but sockmap doesn't operate on it, right? So most likely, the connection is stalled until the userspace realises that and takes an action?
It depends. Sockmap usually runs as a bypass. The user app (like Nginx) has its own native forwarding logic, and sockmap just kicks in to accelerate it. So in known cases, turning off sockmap falls back to the native logic. But if there's no native logic, the connection just stalls.
Good to know, thanks!
So MPTCP request might still be handled by the "native logic" if any?
Yes. If native logic exists, simply blocking the mixing of MPTCP and sockmap should mostly keep the user's app working.
Thanks.