| Message ID | 1677602291-1666-1-git-send-email-alibuda@linux.alibaba.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | net/smc: Introduce BPF injection capability | expand |
On Wed, 1 Mar 2023 00:38:07 +0800 D. Wythe wrote: > From: "D. Wythe" <alibuda@linux.alibaba.com> > > This patches attempt to introduce BPF injection capability for SMC, > and add selftest to ensure code stability. If you cross-posting to net please make sure you follow netdev rules. Don't repost too often.
On 3/1/23 7:02 AM, Jakub Kicinski wrote: > On Wed, 1 Mar 2023 00:38:07 +0800 D. Wythe wrote: >> From: "D. Wythe" <alibuda@linux.alibaba.com> >> >> This patches attempt to introduce BPF injection capability for SMC, >> and add selftest to ensure code stability. > > If you cross-posting to net please make sure you follow netdev rules. > Don't repost too often. I'm very sorry, dues to some low-level errors, so I was anxious to fix such problems. I will pay more attention in the future!! Thanks for your advice. best wishes D. Wythe
On 3/1/23 12:38 AM, D. Wythe wrote: > From: "D. Wythe" <alibuda@linux.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. > > v4 -> v3: > 1. fix compile error and warning > > Reported-by: kernel test robot <lkp@intel.com> > Link: https://lore.kernel.org/oe-kbuild-all/202302282100.x7qq7PGX-lkp@intel.com/ Hi Wenjia and all, I wondering if there are any more questions about this PATCH, This patch seems to have been hanging for some time. If you have any questions, please let me know. Thanks, D. Wythe Do you have any questions about this PATCH? If you have any other questions, please let me know.
On 3/6/23 7:05 PM, D. Wythe wrote: > I wondering if there are any more questions about this PATCH, This patch seems May be start with the questions on v2 first. > to have been hanging for some time. > > If you have any questions, please let me know. > > > Thanks, > > D. Wythe > > > Do you have any questions about this PATCH? If you have any other questions, > please let me know. >
Hi Martin I'm very sorry to see your comments on v2 just now... I just checked the email and found that your reply was filtered out by my email terminal.
From: "D. Wythe" <alibuda@linux.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. v4 -> v3: 1. fix compile error and warning Reported-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/oe-kbuild-all/202302282100.x7qq7PGX-lkp@intel.com/ v3 -> v2: 1. fix checkpatch error and warning. 2. split patch for better review. 3. enhance selftest to cover more scenarios. v2 -> v1: 1. fix compile error and warning. D. Wythe (4): net/smc: move smc_sock related structure definition bpf: add SMC support in BPF struct_ops net/smc: add BPF injection on smc negotiation bpf/selftests: add selftest for SMC bpf capability include/linux/btf_ids.h | 12 + include/net/smc.h | 263 +++++++++++++++++++ kernel/bpf/bpf_struct_ops_types.h | 4 + net/Makefile | 5 + net/smc/af_smc.c | 15 +- net/smc/bpf_smc_struct_ops.c | 148 +++++++++++ net/smc/smc.h | 224 ---------------- tools/testing/selftests/bpf/prog_tests/bpf_smc.c | 37 +++ tools/testing/selftests/bpf/progs/bpf_smc.c | 320 +++++++++++++++++++++++ 9 files changed, 803 insertions(+), 225 deletions(-) create mode 100644 net/smc/bpf_smc_struct_ops.c create mode 100644 tools/testing/selftests/bpf/prog_tests/bpf_smc.c create mode 100644 tools/testing/selftests/bpf/progs/bpf_smc.c