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: kuba@kernel.org, davem@davemloft.net, netdev@vger.kernel.org,
	linux-s390@vger.kernel.org, linux-rdma@vger.kernel.org,
	bpf@vger.kernel.org, kgraul@linux.ibm.com, wenjia@linux.ibm.com,
	jaka@linux.ibm.com, ast@kernel.org, daniel@iogearbox.net,
	andrii@kernel.org
Subject: Re: [PATCH bpf-next v2 1/2] net/smc: Introduce BPF injection capability for SMC
Date: Fri, 24 Mar 2023 16:27:51 -0700	[thread overview]
Message-ID: <fe3db636-2f89-3175-a605-2124b43ae4fa@linux.dev> (raw)
In-Reply-To: <6b4728e0-dfb7-ec7b-630f-87ee42233fe8@linux.alibaba.com>

On 3/23/23 9:08 PM, D. Wythe wrote:
> 
> The latest design is that users can register a negotiator implementation indexed 
> by name, smc_sock can use bpf_setsockopt to specify
> whether a specific negotiation implementation is required via name. If there are 
> no settings, there will be no negotiators.
> 
> What do you think?

tbh, bpf_setsockopt is many steps away. It needs to begin with a syscall 
setsockopt first. There is little reason it can only be done with a bpf prog. 
and how does the user know which negotiator a smc sock is using? Currently, ss 
can learn the tcp-cc of a sk.

~~~~~~~~

If this effort is serious, the code quality has to be much improved. The obvious 
bug and unused variables make this set at most a RFC.

 From the bpf perspective, it is ok-ish to start with a global negotiator first 
and skip the setsockopt details for now. However, it needs to be have a name. 
The new link_update 
(https://lore.kernel.org/bpf/20230323032405.3735486-1-kuifeng@meta.com/) has to 
work also. The struct_ops is rcu reader safe, so leverage it whenever it can 
instead of the read/write lock. It is how struct_ops work for tcp, so try to 
stay consistent as much as possible in the networking stack.

> 
> In addition, I am very sorry that I have not issued my implementation for such a 
> long time, and I have encountered some problems with the implementation because
> the SMC needs to be built as kernel module, I have struggled with the 
> bpf_setsockopt implementation, and there are some new self-testes that need to 
> be written.
> 

Regarding compiling as module,

+ifneq ($(CONFIG_SMC),)
+ifeq ($(CONFIG_BPF_SYSCALL),y)
+obj-y				+= smc/bpf_smc_struct_ops.o
+endif

struct_ops does not support module now. It is on the todo list. The 
bpf_smc_struct_ops.o above can only be used when CONFIG_SMC=y. Otherwise, the 
bpf_smc_struct_ops is always built in while most users will never load the smc 
module.

  reply	other threads:[~2023-03-24 23:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-21 12:18 [PATCH bpf-next v2 0/2] net/smc: Introduce BPF injection capability D. Wythe
2023-02-21 12:18 ` [PATCH bpf-next v2 1/2] net/smc: Introduce BPF injection capability for SMC D. Wythe
2023-02-22 21:40   ` Martin KaFai Lau
2023-03-09 11:49     ` D. Wythe
2023-03-23 20:46       ` Martin KaFai Lau
2023-03-24  4:08         ` D. Wythe
2023-03-24 23:27           ` Martin KaFai Lau [this message]
2023-04-03  8:21             ` D. Wythe
2023-02-27  7:58   ` Wenjia Zhang
2023-02-28  8:50     ` D. Wythe
2023-02-28  8:58       ` Wenjia Zhang
2023-02-21 12:18 ` [PATCH bpf-next v2 2/2] bpf/selftests: add selftest for SMC bpf capability D. Wythe
2023-02-22 22:35   ` Martin KaFai Lau
2023-03-09 11:58     ` 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=fe3db636-2f89-3175-a605-2124b43ae4fa@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=jaka@linux.ibm.com \
    --cc=kgraul@linux.ibm.com \
    --cc=kuba@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=wenjia@linux.ibm.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.