[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fea9adf1-3c61-4213-bc84-9429bf3e82a7@linux.dev>
Date: Tue, 28 Oct 2025 17:30:12 -0700
From: Martin KaFai Lau <martin.lau@...ux.dev>
To: "D. Wythe" <alibuda@...ux.alibaba.com>
Cc: martin.lau@...ux.dev, ast@...nel.org, andrii.nakryiko@...il.com,
daniel@...earbox.net, andrii@...nel.org, pabeni@...hat.com, song@...nel.org,
sdf@...gle.com, haoluo@...gle.com, yhs@...com, edumazet@...gle.com,
john.fastabend@...il.com, kpsingh@...nel.org, jolsa@...nel.org,
mjambigi@...ux.ibm.com, wenjia@...ux.ibm.com, wintera@...ux.ibm.com,
dust.li@...ux.alibaba.com, tonylu@...ux.alibaba.com,
guwen@...ux.alibaba.com, bpf@...r.kernel.org, davem@...emloft.net,
kuba@...nel.org, netdev@...r.kernel.org, sidraya@...ux.ibm.com,
jaka@...ux.ibm.com
Subject: Re: [PATCH bpf-next v3 0/3] net/smc: Introduce smc_hs_ctrl
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.
Powered by blists - more mailing lists