On 05/11/2025 17:12, Jiayuan Chen wrote: > November 5, 2025 at 22:40, "Matthieu Baerts" <[email protected] > mailto:[email protected]?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 <[email protected]> >>> --- >>> .../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 -- Sponsored by the NGI0 Core fund.
