Hi Martin,
On 17/05/2025 00:48, Martin KaFai Lau wrote:
On 3/20/25 10:48 AM, Matthieu Baerts (NGI0) wrote:
From: Geliang Tang tanggeliang@kylinos.cn
This patch adds a "cgroup/getsockopt" program "iters_subflow" to test the newly added mptcp_subflow bpf_iter.
Export mptcp_subflow helpers bpf_iter_mptcp_subflow_new/_next/_destroy and other helpers into bpf_experimental.h.
Use bpf_for_each() to walk the subflow list of an msk. From there, future MPTCP-specific kfunc can be called in the loop. Because they are not there yet, this test doesn't do anything very "useful" for the moment, but it focuses on validating the 'bpf_iter' part and the basic MPTCP kfunc. That's why it simply adds all subflow ids to local variable local_ids to make sure all subflows have been seen, then invoke mptcp_subflow_tcp_sock() in the loop to pick the subflow context.
Out of the loop, use bpf_mptcp_subflow_ctx() to get the subflow context of the picked subflow context and do some verifications. Finally, assign local_ids to global variable ids so that the application can obtain this value.
A related subtest called test_iters_subflow is added to load and verify the newly added mptcp_subflow type bpf_iter example in test_mptcp. The endpoint_init() helper is used to add 3 new subflow endpoints. Then one byte of message is sent to trigger the creation of new subflows. getsockopt() is invoked once the subflows have been created to trigger the "cgroup/getsockopt" test program "iters_subflow". skel->bss->ids is then checked to make sure it equals 10, the sum of each subflow ID: we should have 4 subflows: 1 + 2 + 3 + 4 = 10. If that's the case, the bpf_iter loop did the job as expected.
(...)
diff --git a/tools/testing/selftests/bpf/progs/mptcp_bpf_iters.c b/ tools/testing/selftests/bpf/progs/mptcp_bpf_iters.c new file mode 100644 index 0000000000000000000000000000000000000000..a1d8f9b20259a9cbdc46d58e0d18157564fa5acd --- /dev/null +++ b/tools/testing/selftests/bpf/progs/mptcp_bpf_iters.c @@ -0,0 +1,59 @@ +// SPDX-License-Identifier: GPL-2.0 +/* Copyright (c) 2024, Kylin Software */
+/* vmlinux.h, bpf_helpers.h and other 'define' */ +#include "bpf_tracing_net.h" +#include "mptcp_bpf.h"
+char _license[] SEC("license") = "GPL"; +int ids;
+#ifndef TCP_IS_MPTCP +#define TCP_IS_MPTCP 43 /* Is MPTCP being used? */ +#endif
+SEC("cgroup/getsockopt") +int iters_subflow(struct bpf_sockopt *ctx) +{ + struct mptcp_subflow_context *subflow; + struct bpf_sock *sk = ctx->sk; + struct sock *ssk = NULL; + struct mptcp_sock *msk; + int local_ids = 0;
+ if (ctx->level != SOL_TCP || ctx->optname != TCP_IS_MPTCP) + return 1;
+ msk = bpf_core_cast(sk, struct mptcp_sock); + if (!msk || msk->pm.server_side || !msk->pm.subflows) + return 1;
+ bpf_for_each(mptcp_subflow, subflow, (struct sock *)sk) { + /* Here MPTCP-specific packet scheduler kfunc can be called: + * this test is not doing anything really useful, only to
Lets fold the bpf_iter_mptcp_subflow addition into the future "mptcp_sched_ops" set (the github link that you mentioned in patch 2). Post them as one set to have a more practical example.
Thank you for this suggestion. We can delay that if needed.
Note that we have two struct_ops in preparation: mptcp_sched_ops and mptcp_pm_ops. We don't know which one will be ready first. They are both "blocked" by internal API modifications we would like to do to ease the maintenance later before "exposing" such API's via BPF. That's why we suggested to upstream this common part first as it is ready. But we can of course wait if you prefer.
+ * verify the iteration works. + */
+ local_ids += subflow->subflow_id;
+ /* only to check the following helper works */ + ssk = mptcp_subflow_tcp_sock(subflow); + }
+ if (!ssk) + goto out;
+ /* assert: if not OK, something wrong on the kernel side */ + if (ssk->sk_dport != ((struct sock *)msk)->sk_dport) + goto out;
+ /* only to check the following kfunc works */ + subflow = bpf_mptcp_subflow_ctx(ssk);
bpf_core_cast should be as good instead of adding a new bpf_mptcp_subflow_ctx() kfunc, so patch 1 should not be needed.
OK, indeed, in this series we don't need it. We will need it later to modify some fields from the "subflow" structure directly. We can do the modification or drop this test when the new struct_ops will be ready.
+ if (!subflow || subflow->token != msk->token) + goto out;
+ ids = local_ids;
+out: + return 1; +}
Cheers, Matt