November 6, 2025 at 24:28, "Matthieu Baerts" <[email protected] mailto:[email protected]?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" <[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. 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.
