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.
(...)
- return;
- skel->bss->trace_port = ntohs(get_socket_local_port(listen_fd));
- skel->bss->sk_index = 0;
- /* create client with MPTCP enabled */
- client_fd1 = connect_to_fd(listen_fd, 0);
- if (!ASSERT_OK_FD(client_fd1, "connect_to_fd client_fd1"))
- goto end;
- /* bpf_sock_map_update() called from sockops should reject MPTCP sk */
- if (!ASSERT_EQ(skel->bss->helper_ret, -EOPNOTSUPP, "should reject"))
- goto end;
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?
Cheers, Matt