From: Martin KaFai Lau <martin.lau@linux.dev>
To: "D. Wythe" <alibuda@linux.alibaba.com>
Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
pabeni@redhat.com, song@kernel.org, sdf@google.com,
haoluo@google.com, yhs@fb.com, edumazet@google.com,
john.fastabend@gmail.com, kpsingh@kernel.org, jolsa@kernel.org,
mjambigi@linux.ibm.com, wenjia@linux.ibm.com,
wintera@linux.ibm.com, dust.li@linux.alibaba.com,
tonylu@linux.alibaba.com, guwen@linux.alibaba.com,
bpf@vger.kernel.org, davem@davemloft.net, kuba@kernel.org,
netdev@vger.kernel.org, sidraya@linux.ibm.com,
jaka@linux.ibm.com
Subject: Re: [PATCH bpf-next v4 2/3] net/smc: bpf: Introduce generic hook for handshake flow
Date: Wed, 5 Nov 2025 14:58:48 -0800 [thread overview]
Message-ID: <dfed97fb-4e0c-416e-b5d8-8de7b3edce69@linux.dev> (raw)
In-Reply-To: <20251105070140.GA31761@j66a10360.sqa.eu95>
On 11/4/25 11:01 PM, D. Wythe wrote:
> On Tue, Nov 04, 2025 at 04:03:46PM -0800, Martin KaFai Lau wrote:
>>
>>
>> On 11/2/25 11:31 PM, D. Wythe wrote:
>>> +#if IS_ENABLED(CONFIG_SMC_HS_CTRL_BPF)
>>> +#define smc_call_hsbpf(init_val, sk, func, ...) ({ \
>>> + typeof(init_val) __ret = (init_val); \
>>> + struct smc_hs_ctrl *ctrl; \
>>> + rcu_read_lock(); \
>>> + ctrl = rcu_dereference(sock_net(sk)->smc.hs_ctrl); \
>>
>> The smc_hs_ctrl (and its ops) is called from the netns, so the
>> bpf_struct_ops is attached to a netns. Attaching bpf_struct_ops to a
>> netns has not been done before. More on this later.
>>
>>> + if (ctrl && ctrl->func) \
>>> + __ret = ctrl->func(__VA_ARGS__); \
>>> +
>>> + if (static_branch_unlikely(&tcp_have_smc) && tp->syn_smc) {
>>> + tp->syn_smc = !!smc_call_hsbpf(1, sk, syn_option, tp);
>>
>> ... so just pass tp instead of passing both sk and tp?
>>
>> [ ... ]
>>
>
> You're right, it is a bit redundant. However, if we merge the parameters,
> every user of this macro will be forced to pass tp. In fact, we’re
> already considering adding some callback functions that don’t take tp as
> a parameter.
If the struct_ops callback does not take tp, then don't pass it to the
callback. I have a hard time to imagine why the bpf prog will not be
interested in the tp/sk pointer though.
or you meant the caller does not have tp? and where is the future caller?
>
> I’ve been considering this: since smc_hs_ctrl is called from the netns,
> maybe we should replace the sk parameter with netns directly. After all,
> the only reason we pass sk here is to extract sock_net(sk). Doing so
> would remove the redundancy and also keep the interface more flexible
> for future extensions. What do you think?
The net can be obtained from the tp also.
Like in this patch, all the caller needs to type
"const struct sock *sk = &tp->inet_conn.icsk_inet.sk;". I can imagine all
the callers will have to type "sock_net((struct sock *)tp)" if passing net.
Why not just do that in the smc_hs_ctrl instead of asking all the callers
to type that?
I meant something like this (untested):
-#define smc_call_hsbpf(init_val, sk, func, ...) ({ \
+#define smc_call_hsbpf(init_val, func, tp, ...) ({ \
typeof(init_val) __ret = (init_val); \
struct smc_hs_ctrl *ctrl; \
rcu_read_lock(); \
- ctrl = rcu_dereference(sock_net(sk)->smc.hs_ctrl); \
+ ctrl = rcu_dereference(sock_net((struct sock *)(tp))->smc.hs_ctrl); \
if (ctrl && ctrl->func) \
- __ret = ctrl->func(__VA_ARGS__); \
+ __ret = ctrl->func(tp, ##__VA_ARGS__); \
rcu_read_unlock(); \
__ret; \
})
next prev parent reply other threads:[~2025-11-05 22:59 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-03 7:31 [PATCH bpf-next v4 0/3] net/smc: Introduce smc_hs_ctrl D. Wythe
2025-11-03 7:31 ` [PATCH bpf-next v4 1/3] bpf: export necessary symbols for modules with struct_ops D. Wythe
2025-11-03 7:31 ` [PATCH bpf-next v4 2/3] net/smc: bpf: Introduce generic hook for handshake flow D. Wythe
2025-11-03 7:55 ` bot+bpf-ci
2025-11-03 9:18 ` D. Wythe
2025-11-05 0:03 ` Martin KaFai Lau
2025-11-05 7:01 ` D. Wythe
2025-11-05 22:58 ` Martin KaFai Lau [this message]
2025-11-06 2:33 ` D. Wythe
2025-11-06 4:16 ` Martin KaFai Lau
2025-11-06 8:34 ` D. Wythe
2025-11-06 17:15 ` Martin KaFai Lau
2025-11-07 3:11 ` D. Wythe
2025-11-03 7:31 ` [PATCH bpf-next v4 3/3] bpf/selftests: add selftest for bpf_smc_hs_ctrl D. Wythe
2025-11-05 0:13 ` Martin KaFai Lau
2025-11-05 7:04 ` D. Wythe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dfed97fb-4e0c-416e-b5d8-8de7b3edce69@linux.dev \
--to=martin.lau@linux.dev \
--cc=alibuda@linux.alibaba.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dust.li@linux.alibaba.com \
--cc=edumazet@google.com \
--cc=guwen@linux.alibaba.com \
--cc=haoluo@google.com \
--cc=jaka@linux.ibm.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=mjambigi@linux.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@google.com \
--cc=sidraya@linux.ibm.com \
--cc=song@kernel.org \
--cc=tonylu@linux.alibaba.com \
--cc=wenjia@linux.ibm.com \
--cc=wintera@linux.ibm.com \
--cc=yhs@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.