Re: [PATCH mptcp-next v3 1/2] mptcp: add bpf_iter_task for mptcp_sock

[Matthieu Baerts <matttbe@kernel.org>]

On 21/03/2025 11:05, Geliang Tang wrote:
> Hi Matt,
> 
> On Fri, 2025-03-21 at 10:19 +0100, Matthieu Baerts wrote:
>> Hi Geliang,
>>
>> On 21/03/2025 05:14, Geliang Tang wrote:
>>> On Tue, 2025-03-18 at 12:26 +0100, Matthieu Baerts wrote:
>>
>> (...)
>>
>>>> Mmh, all 8 callbacks from add_addr to here seem to be linked to
>>>> Netlink
>>>> commands, right? If yes, they should not be here: they don't make
>>>> sense
>>>> for a BPF PM, no? BPF PMs should be configured with BPF, and not
>>>> via
>>>
>>> Do you have any idea how we can pass commands like ADD_ADDR and
>>> addresses from user space to BPF?
>>
>> The userspace can inject any kind of BPF program. Additional
>> addresses
>> can then be hardcoded in this program, or it can load them from eBPF
>> maps, or read skel->bss->(...), etc.
>>
>> Netlink is then not needed.
>>
>>> What I can think of is passing through sockopt, the user space
>>> passes
>>> the command and the address through setsockopt, and the BPF program
>>> handles it through the custom "cgroup/setsockopt". I would like to
>>> hear
>>> your opinions. If you also agree to use sockopt to implement it, I
>>> can
>>> write a test program for this.
> 
> I just tested it and found it difficult to use setsockopt.
> 
> "cgroup/setsockopt" program doesn't work. We need to invoke sleepable
> kfuncs in BPF PM:

(...)

> It seems that we can only choose one of fentry/fexit/fmod_ret, lsm,
> iter, uprobe, or struct_ops type to implement BPF PM.
Thank you for having checked. I think we can look at that aspect later.
I don't think many apps will want this kind of control. They can always
set something in a map, and the BPF program can look at it when needed.

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