[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <366b9486-9a00-6add-d54b-5c3f4d35afe9@linux.dev>
Date: Thu, 23 Mar 2023 13:46:40 -0700
From: Martin KaFai Lau <martin.lau@...ux.dev>
To: "D. Wythe" <alibuda@...ux.alibaba.com>
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, kgraul@...ux.ibm.com, wenjia@...ux.ibm.com,
jaka@...ux.ibm.com, ast@...nel.org, daniel@...earbox.net,
andrii@...nel.org
Subject: Re: [PATCH bpf-next v2 1/2] net/smc: Introduce BPF injection
capability for SMC
On 3/9/23 3:49 AM, D. Wythe wrote:
>>> --- /dev/null
>>> +++ b/net/smc/bpf_smc_struct_ops.c
>>> @@ -0,0 +1,146 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +
>>> +#include <linux/kernel.h>
>>> +#include <linux/bpf_verifier.h>
>>> +#include <linux/btf_ids.h>
>>> +#include <linux/bpf.h>
>>> +#include <linux/btf.h>
>>> +#include <net/sock.h>
>>> +#include <net/smc.h>
>>> +
>>> +extern struct bpf_struct_ops smc_sock_negotiator_ops;
>>> +
>>> +DEFINE_RWLOCK(smc_sock_negotiator_ops_rwlock);
>>> +struct smc_sock_negotiator_ops *negotiator;
>>
>> Is it sure one global negotiator (policy) will work for all smc_sock? or each
>> sk should have its own negotiator and the negotiator is selected by setsockopt.
>>
> This is really a good question, we can really consider adding an independent
> negotiator for each sock.
>
> But just like the TCP congestion control , the global negotiator can be used for
> sock without
>
> special requirements.
It is different from TCP congestion control (CC). TCP CC has a global default
but each sk can select what tcp-cc to use and there can be multiple tcp-cc
registered under different names.
It sounds like smc using tcp_sock should be able to have different negotiator
also (eg. based on dst IP or some other tcp connection characteristic). The
tcp-cc registration, per-sock selection and the rcu_read_lock+refcnt are well
understood and there are other bpf infrastructure to support the per sock tcp-cc
selection (like bpf_setsockopt).
For the network stack, there is little reason other af_* should not follow at
the beginning considering the infrastructure has already been built. The one
single global negotiator and reader/writer lock in this patch reads like an
effort wanted to give it a try and see if it will be useful before implementing
the whole thing. It is better to keep it off the tree for now until it is more
ready.
Powered by blists - more mailing lists