Re: [PATCH net v3 0/3] mptcp: Fix conflicts between MPTCP and sockmap

[Matthieu Baerts <matttbe@kernel.org>]

Hi Jiayuan,

On 03/11/2025 13:34, Jiayuan Chen wrote:
> October 29, 2025 at 1:26 AM, "Matthieu Baerts" <matttbe@kernel.org mailto:matttbe@kernel.org?to=%22Matthieu%20Baerts%22%20%3Cmatttbe%40kernel.org%3E > wrote:
>> On 24/10/2025 06:13, Jiayuan Chen wrote:

(...)

>>> The current implementation rejects MPTCP because I previously attempted to
>>>  add sockmap support for MPTCP, but it required implementing many interfaces
>>>  and would take considerable time.
>>>  
>>>  So for now, I'm proposing this as a fix to resolve the immediate issue.
>>>  Subsequently, we can continue working on fully integrating MPTCP with sockmap.
>>>
>> It makes sense to start with the fix for stable, then the implementation
>> later. I think the implementation should not be that complex: it is just
>> that it has to be done at MPTCP level, not TCP. sockmap supports
>> different protocol, and it doesn't seem to be TCP specific, so that
>> should be feasible.
> 
> I agree with that. From a userspace perspective, we can't really manipulate subflow
> TCP directly, and I also think it's correct to handle this at the MPTCP layer.
> 
> But I didn't quite get your point about "it has to be done at MPTCP level." Currently,
> BPF provides 'sockops' capability, which invokes BPF programs in the protocol stack.
> The input parameter sk for the BPF program is actually a TCP sk (subflow).
> 
> Many helper functions (like sockmap) have no choice but to care about whether it's MPTCP
> or not.

I see. Maybe new MPTCP equivalent hooks will be needed then?

(...)

>>>> A more important question: what will typically happen in your case if
>>>>  you receive an MPTCP request and sockmap is then not supported? Will the
>>>>  connection be rejected or stay in a strange state because the userspace
>>>>  will not expect that? In these cases, would it not be better to disallow
>>>>  sockmap usage while the MPTCP support is not available? The userspace
>>>>  would then get an error from the beginning that the protocol is not
>>>>  supported, and should then not create an MPTCP socket in this case for
>>>>  the moment, no?
>>>>
>>>>  I can understand that the switch from TCP to MPTCP was probably done
>>>>  globally, and this transition should be as seamless as possible, but it
>>>>  should not cause a regression with MPTCP requests. An alternative could
>>>>  be to force a fallback to TCP when sockmap is used, even when an MPTCP
>>>>  request is received, but not sure if it is practical to do, and might be
>>>>  strange from the user point of view.
>>>>
>>>  
>>>  Actually, I understand this not as an MPTCP regression, but as a sockmap
>>>  regression.
>>>  
>>>  Let me explain how users typically use sockmap:
>>>  
>>>  Users typically create multiple sockets on a host and program using BPF+sockmap
>>>  to enable fast data redirection. This involves intercepting data sent or received
>>>  by one socket and redirecting it to the send or receive queue of another socket.
>>>  
>>>  This requires explicit user programming. The goal is that when multiple microservices
>>>  on one host need to communicate, they can bypass most of the network stack and avoid
>>>  data copies between user and kernel space.
>>>  
>>>  However, when an MPTCP request occurs, this redirection flow fails.
>>>
>> This part bothers me a bit. Does it mean that when the userspace creates
>> a TCP listening socket (IPPROTO_TCP), MPTCP requests will be accepted,
>> but MPTCP will not be used ; but when an MPTCP socket is used instead,
>> MPTCP requests will be rejected?
> 
> "when the userspace creates a TCP listening socket (IPPROTO_TCP), MPTCP requests will be accepted,
> but MPTCP will not be used"
> --- Yes, that's essentially the logic behind MPTCP fallback, right? In this case, it should work
> fine with sockmap as well. That's exactly what this patch aims to achieve.

That's an MPTCP fallback to TCP for the client side here: the client
requests to use MPTCP, but the server doesn't support it. In this case,
MPTCP options will be ignored, and a "plain" TCP SYN+ACK will be sent
back to the client. In this case, the server using sockmap doesn't
handle MPTCP, because it created an IPPROTO_TCP.

In other words, the situation you had before GO 1.24, right?

> "but when an MPTCP socket is used instead, MPTCP requests will be rejected?"
> --- Exactly. Currently, because sockmap operates directly on the subflow sk, it breaks the MPTCP
> connection. The purpose of this patch is to explicitly return an error when users try to replace
> certain handlers of the subflow sk.

I don't think a message at that point is that useful. Ideally, the
userspace should get an error or a notice when setting sockmap up. But I
understand sockmap are not really attached to listening sockets, and it
doesn't seem possible to block sockmap at setup time because it is going
to be used with "accept()ed" connection created from an MPTCP listening
socket.

So I guess we will still need patch 1/3 (with a better commit message),
and patch 2/3 should be restricted to remove psock_update_sk_prot for
MPTCP subflows.

> This way, users at least get a clear error message instead of just experiencing a mysterious connection
> failure.
> 
>> If yes, it might be clearer not to allow sockmap on connections created
>> from MPTCP sockets. But when looking at sockmap and what's happening
>> when a TCP socket is created following a "plain TCP" request, we would
>> need specific MPTCP code to catch that in sockmap...
> 
> I know what you're concerned about, and I also don't want to add any MPTCP-specific checks on the
> sockmap or BPF side :).
> 
> I will try to set psock_update_sk_prot to NULL first.

Thanks!

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