Message-ID: <3990a85c-c8d9-d20d-0c6d-f111ed872b7a@linux.alibaba.com>
Date:   Fri, 21 Apr 2023 12:31:12 +0800
From:   "D. Wythe" <alibuda@...ux.alibaba.com>
To:     Martin KaFai Lau <martin.lau@...ux.dev>
Cc:     kuba@...nel.org, davem@...emloft.net, netdev@...r.kernel.org,
        linux-s390@...r.kernel.org, linux-rdma@...r.kernel.org,
        bpf@...r.kernel.org
Subject: Re: [RFC PATCH bpf-next v3 0/5] net/smc: Introduce BPF injection
 capability


Hi Martin,

At now, most of the issues you mentioned have been resolved, mainly 
including

1. Use RCU instead of read write lock
2. Support for update
3. Negotiator requires a name
4. Added a KConfig with a default value of N to avoid affecting users 
who do not require SMC.
5. Revised some issues with test cases.

Do you have any other suggestions? If any, please let me know. Thank a 
lot! 😁
If there are no other opinions, I plan to convert the RFC into a formal 
PATCH.
What do you think?

Best wishes
D. Wythe


On 4/21/23 12:23 PM, D. Wythe wrote:
> From: "D. Wythe" <alibuda@...ux.alibaba.com>
>
> This patches attempt to introduce BPF injection capability for SMC,
> and add selftest to ensure code stability.
>
> As we all know that the SMC protocol is not suitable for all scenarios,
> especially for short-lived. However, for most applications, they cannot
> guarantee that there are no such scenarios at all. Therefore, apps
> may need some specific strategies to decide shall we need to use SMC
> or not, for example, apps can limit the scope of the SMC to a specific
> IP address or port.
>
> Based on the consideration of transparent replacement, we hope that apps
> can remain transparent even if they need to formulate some specific
> strategies for SMC using. That is, do not need to recompile their code.
>
> On the other hand, we need to ensure the scalability of strategies
> implementation. Although it is simple to use socket options or sysctl,
> it will bring more complexity to subsequent expansion.
>
> Fortunately, BPF can solve these concerns very well, users can write
> thire own strategies in eBPF to choose whether to use SMC or not.
> And it's quite easy for them to modify their strategies in the future.
>
> This patches implement injection capability for SMC via struct_ops.
> In that way, we can add new injection scenarios in the future.
>
> v3 -> v2:
>
> 1. Fix format errors in subject.
> 2. Remove unnecessary conditions in Kconfig.
>
> v2 -> v1:
>
> 1. Fix complie error if CONFIG_BPF_SYSCALL set while CONFIG_SMC_BPF not.
> Reported-by: kernel test robot <lkp@...el.com>
> Link: https://lore.kernel.org/oe-kbuild-all/202304070326.mYVdiX9k-lkp@intel.com/
>
> 2. Fix potential reference leaks, smc_destruct may be prematurely retired
> due to pre conditions.
>
> D. Wythe (5):
>    net/smc: move smc_sock related structure definition
>    net/smc: allow smc to negotiate protocols on policies
>    net/smc: allow set or get smc negotiator by sockopt
>    bpf: add smc negotiator support in BPF struct_ops
>    bpf/selftests: add selftest for SMC bpf capability
>
>   include/net/smc.h                                | 268 +++++++++++++++++
>   include/uapi/linux/smc.h                         |   1 +
>   kernel/bpf/bpf_struct_ops_types.h                |   4 +
>   net/Makefile                                     |   1 +
>   net/smc/Kconfig                                  |  11 +
>   net/smc/af_smc.c                                 | 203 ++++++++++---
>   net/smc/bpf_smc.c                                | 360 +++++++++++++++++++++++
>   net/smc/smc.h                                    | 224 --------------
>   tools/testing/selftests/bpf/prog_tests/bpf_smc.c | 107 +++++++
>   tools/testing/selftests/bpf/progs/bpf_smc.c      | 265 +++++++++++++++++
>   10 files changed, 1185 insertions(+), 259 deletions(-)
>   create mode 100644 net/smc/bpf_smc.c
>   create mode 100644 tools/testing/selftests/bpf/prog_tests/bpf_smc.c
>   create mode 100644 tools/testing/selftests/bpf/progs/bpf_smc.c
>

Powered by blists - more mailing lists