From: Martin KaFai Lau <martin.lau@linux.dev>
To: "D. Wythe" <alibuda@linux.alibaba.com>
Cc: martin.lau@linux.dev, ast@kernel.org, andrii.nakryiko@gmail.com,
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 v3 0/3] net/smc: Introduce smc_hs_ctrl
Date: Tue, 28 Oct 2025 17:30:12 -0700 [thread overview]
Message-ID: <fea9adf1-3c61-4213-bc84-9429bf3e82a7@linux.dev> (raw)
In-Reply-To: <20251028121531.GA51645@j66a10360.sqa.eu95>
On 10/28/25 5:15 AM, D. Wythe wrote:
> On Mon, Sep 29, 2025 at 02:33:57PM +0800, D. Wythe wrote:
>> This patch aims to introduce BPF injection capabilities for SMC and
>> includes a self-test to ensure code stability.
>>
>> Since the SMC protocol isn't ideal for every situation, especially
>> short-lived ones, most applications can't guarantee the absence of
>> such scenarios. Consequently, applications may need specific strategies
>> to decide whether to use SMC. For example, an application might limit SMC
>> usage to certain IP addresses or ports.
>>
>> To maintain the principle of transparent replacement, we want applications
>> to remain unaffected even if they need specific SMC strategies. In other
>> words, they should not require recompilation of their code.
>>
>> Additionally, we need to ensure the scalability of strategy implementation.
>> While using socket options or sysctl might be straightforward, it could
>> complicate future expansions.
>>
>> Fortunately, BPF addresses these concerns effectively. Users can write
>> their own strategies in eBPF to determine whether to use SMC, and they can
>> easily modify those strategies in the future.
>>
>> This is a rework of the series from [1]. Changes since [1] are limited to
>> the SMC parts:
>>
>> 1. Rename smc_ops to smc_hs_ctrl and change interface name.
>> 2. Squash SMC patches, removing standalone non-BPF hook capability.
>> 3. Fix typos
>
>
> Hi bpf folks,
>
> I've noticed this patch has been pending for a while, and I wanted to
> gently check in. Is there any specific concerns or feedback regarding
> it from the BPF side? I'm keen to address any issues and move it
> forward.
The original v1 started last year. The bpf side had been responsive but
the progress stopped for months and the smc side review had been slow
also. I doubt how well will this be supported in the future and put this
to the bottom of my list since then.
The set does not apply on bpf-next/net now. Please re-spin.
next prev parent reply other threads:[~2025-10-29 0:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-29 6:33 [PATCH bpf-next v3 0/3] net/smc: Introduce smc_hs_ctrl D. Wythe
2025-09-29 6:33 ` [PATCH bpf-next v3 1/3] bpf: export necessary symbols for modules with struct_ops D. Wythe
2025-09-29 6:33 ` [PATCH bpf-next v3 2/3] net/smc: bpf: Introduce generic hook for handshake flow D. Wythe
2025-09-29 14:21 ` Dust Li
2025-09-29 6:34 ` [PATCH bpf-next v3 3/3] bpf/selftests: add selftest for bpf_smc_hs_ctrl D. Wythe
2025-10-28 12:15 ` [PATCH bpf-next v3 0/3] net/smc: Introduce smc_hs_ctrl D. Wythe
2025-10-29 0:30 ` Martin KaFai Lau [this message]
2025-10-29 6:14 ` 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=fea9adf1-3c61-4213-bc84-9429bf3e82a7@linux.dev \
--to=martin.lau@linux.dev \
--cc=alibuda@linux.alibaba.com \
--cc=andrii.nakryiko@gmail.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.