All of lore.kernel.org
 help / color / mirror / Atom feed
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.


  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.