public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
From: "D. Wythe" <alibuda@linux.alibaba.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: kgraul@linux.ibm.com, wenjia@linux.ibm.com, jaka@linux.ibm.com,
	wintera@linux.ibm.com, guwen@linux.alibaba.com,
	Alexei Starovoitov <ast@kernel.org>,
	Jakub Kicinski <kuba@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Network Development <netdev@vger.kernel.org>,
	linux-s390 <linux-s390@vger.kernel.org>,
	linux-rdma@vger.kernel.org, Tony Lu <tonylu@linux.alibaba.com>,
	Paolo Abeni <pabeni@redhat.com>,
	Eric Dumazet <edumazet@google.com>, bpf <bpf@vger.kernel.org>
Subject: Re: [PATCH net-next] net/smc: Introduce a hook to modify syn_smc at runtime
Date: Fri, 11 Oct 2024 14:43:56 +0800	[thread overview]
Message-ID: <b5aa477d-a4b1-45cb-af44-bd737504734e@linux.alibaba.com> (raw)
In-Reply-To: <CAADnVQLXyA__zdDSiTdhaw=dXyfgmkr--cH068JvNK=JAYvRDA@mail.gmail.com>



On 10/11/24 12:21 AM, Alexei Starovoitov wrote:
> On Wed, Oct 9, 2024 at 8:58 PM D. Wythe <alibuda@linux.alibaba.com> wrote:
>>
>>
>> +__bpf_hook_start();
>> +
>> +__weak noinline int select_syn_smc(const struct sock *sk, struct sockaddr *peer)
>> +{
>> +       return 1;
>> +}
>> +
>> +__bpf_hook_end();
>> +
>>   int smc_nl_dump_hs_limitation(struct sk_buff *skb, struct netlink_callback *cb)
>>   {
>>          struct smc_nl_dmp_ctx *cb_ctx = smc_nl_dmp_ctx(cb);
>> @@ -156,19 +165,43 @@ static struct sock *smc_tcp_syn_recv_sock(const struct sock *sk,
>>          return NULL;
>>   }
>>
>> -static bool smc_hs_congested(const struct sock *sk)
>> +static void smc_openreq_init(struct request_sock *req,
>> +                            const struct tcp_options_received *rx_opt,
>> +                            struct sk_buff *skb, const struct sock *sk)
>>   {
>> +       struct inet_request_sock *ireq = inet_rsk(req);
>> +       struct sockaddr_storage rmt_sockaddr = {};
>>          const struct smc_sock *smc;
>>
>>          smc = smc_clcsock_user_data(sk);
>>
>>          if (!smc)
>> -               return true;
>> +               return;
>>
>> -       if (workqueue_congested(WORK_CPU_UNBOUND, smc_hs_wq))
>> -               return true;
>> +       if (smc->limit_smc_hs && workqueue_congested(WORK_CPU_UNBOUND, smc_hs_wq))
>> +               goto out_no_smc;
>>
>> -       return false;
>> +       rmt_sockaddr.ss_family = sk->sk_family;
>> +
>> +       if (rmt_sockaddr.ss_family == AF_INET) {
>> +               struct sockaddr_in *rmt4_sockaddr =  (struct sockaddr_in *)&rmt_sockaddr;
>> +
>> +               rmt4_sockaddr->sin_addr.s_addr = ireq->ir_rmt_addr;
>> +               rmt4_sockaddr->sin_port = ireq->ir_rmt_port;
>> +#if IS_ENABLED(CONFIG_IPV6)
>> +       } else {
>> +               struct sockaddr_in6 *rmt6_sockaddr =  (struct sockaddr_in6 *)&rmt_sockaddr;
>> +
>> +               rmt6_sockaddr->sin6_addr = ireq->ir_v6_rmt_addr;
>> +               rmt6_sockaddr->sin6_port = ireq->ir_rmt_port;
>> +#endif /* CONFIG_IPV6 */
>> +       }
>> +
>> +       ireq->smc_ok = select_syn_smc(sk, (struct sockaddr *)&rmt_sockaddr);
>> +       return;
>> +out_no_smc:
>> +       ireq->smc_ok = 0;
>> +       return;
>>   }
>>
>>   struct smc_hashinfo smc_v4_hashinfo = {
>> @@ -1671,7 +1704,7 @@ int smc_connect(struct socket *sock, struct sockaddr *addr,
>>          }
>>
>>          smc_copy_sock_settings_to_clc(smc);
>> -       tcp_sk(smc->clcsock->sk)->syn_smc = 1;
>> +       tcp_sk(smc->clcsock->sk)->syn_smc = select_syn_smc(sk, addr);
>>          if (smc->connect_nonblock) {
>>                  rc = -EALREADY;
>>                  goto out;
>> @@ -2650,8 +2683,7 @@ int smc_listen(struct socket *sock, int backlog)
>>
>>          inet_csk(smc->clcsock->sk)->icsk_af_ops = &smc->af_ops;
>>
>> -       if (smc->limit_smc_hs)
>> -               tcp_sk(smc->clcsock->sk)->smc_hs_congested = smc_hs_congested;
>> +       tcp_sk(smc->clcsock->sk)->smc_openreq_init = smc_openreq_init;
>>
>>          rc = kernel_listen(smc->clcsock, backlog);
>>          if (rc) {
>> @@ -3475,6 +3507,24 @@ static void __net_exit smc_net_stat_exit(struct net *net)
>>          .exit = smc_net_stat_exit,
>>   };
>>
>> +#if IS_ENABLED(CONFIG_BPF_SYSCALL)
>> +BTF_SET8_START(bpf_smc_fmodret_ids)
>> +BTF_ID_FLAGS(func, select_syn_smc)
>> +BTF_SET8_END(bpf_smc_fmodret_ids)
>> +
>> +static const struct btf_kfunc_id_set bpf_smc_fmodret_set = {
>> +       .owner = THIS_MODULE,
>> +       .set   = &bpf_smc_fmodret_ids,
>> +};
>> +
>> +static int bpf_smc_kfunc_init(void)
>> +{
>> +       return register_btf_fmodret_id_set(&bpf_smc_fmodret_set);
>> +}
> 
> fmodret was an approach that hid-bpf took initially,
> but eventually they removed it all and switched to struct-ops approach.
> Please learn that lesson.
> Use struct_ops from the beginning.
> 
> I did a presentation recently explaining the motivation behind
> struct_ops and tips on how to extend the kernel.
> TLDR: the step one is to design the extension _without_ bpf.
> The interface should be usable for kernel modules.
> And then when you have *_ops style api in place
> the bpf progs will plug-in without extra work.
> 
> Slides:
> https://github.com/4ast/docs/blob/main/BPF%20struct-ops.pdf


Hi Alexei,

Thanks very much for your suggestion.

In fact, I tried struct_ops in SMC about a year ago. Unfortunately, at that time struct_ops did not 
support registration from modules, and I had to move some smc dependencies into bpf, which met with 
community opposition. However, I noticed that this feature is now supported, so perhaps this is an 
opportunity.

But on the other hand, given the current functionality, I wonder if struct_ops might be an overkill. 
I haven't been able to come up with a suitable abstraction to define this ops, and in the future, 
this ops might only contain the very one callback (select_syn_smc).

Looking forward for your advises.

Thanks,
D. Wythe




  reply	other threads:[~2024-10-11  6:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-10  3:58 [PATCH net-next] net/smc: Introduce a hook to modify syn_smc at runtime D. Wythe
2024-10-10 16:21 ` Alexei Starovoitov
2024-10-11  6:43   ` D. Wythe [this message]
2024-10-11 15:37     ` Alexei Starovoitov
2024-10-14  5:49       ` 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=b5aa477d-a4b1-45cb-af44-bd737504734e@linux.alibaba.com \
    --to=alibuda@linux.alibaba.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=guwen@linux.alibaba.com \
    --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=pabeni@redhat.com \
    --cc=tonylu@linux.alibaba.com \
    --cc=wenjia@linux.ibm.com \
    --cc=wintera@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox