netdev - Re: [PATCH bpf-next v2 5/5] bpf/selftests: add simple selftest for bpf_smc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAADnVQJisbHFpS2==pw4aOAmKsbo6m6EDvOBntF_ATMrbp0G=w@mail.gmail.com>
Date: Tue, 10 Dec 2024 10:01:38 -0800
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: "D. Wythe" <alibuda@...ux.alibaba.com>
Cc: kgraul@...ux.ibm.com, wenjia@...ux.ibm.com, jaka@...ux.ibm.com, 
	Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, 
	Andrii Nakryiko <andrii@...nel.org>, Martin KaFai Lau <martin.lau@...ux.dev>, 
	Paolo Abeni <pabeni@...hat.com>, Song Liu <song@...nel.org>, Stanislav Fomichev <sdf@...gle.com>, 
	Hao Luo <haoluo@...gle.com>, Yonghong Song <yhs@...com>, Eric Dumazet <edumazet@...gle.com>, 
	John Fastabend <john.fastabend@...il.com>, KP Singh <kpsingh@...nel.org>, 
	Jiri Olsa <jolsa@...nel.org>, guwen@...ux.alibaba.com, 
	Jakub Kicinski <kuba@...nel.org>, "David S. Miller" <davem@...emloft.net>, 
	Network Development <netdev@...r.kernel.org>, linux-s390 <linux-s390@...r.kernel.org>, 
	linux-rdma@...r.kernel.org, bpf <bpf@...r.kernel.org>
Subject: Re: [PATCH bpf-next v2 5/5] bpf/selftests: add simple selftest for bpf_smc_ops

On Mon, Dec 9, 2024 at 8:04 PM D. Wythe <alibuda@...ux.alibaba.com> wrote:
>
> +SEC("struct_ops/bpf_smc_set_tcp_option_cond")
> +int BPF_PROG(bpf_smc_set_tcp_option_cond, const struct tcp_sock *tp, struct inet_request_sock *ireq)
> +{
> +       return 0;
> +}
> +
> +SEC("struct_ops/bpf_smc_set_tcp_option")
> +int BPF_PROG(bpf_smc_set_tcp_option, struct tcp_sock *tp)
> +{
> +       return 1;
> +}
> +
> +SEC(".struct_ops.link")
> +struct smc_ops  sample_smc_ops = {
> +       .name                   = "sample",
> +       .set_option             = (void *) bpf_smc_set_tcp_option,
> +       .set_option_cond        = (void *) bpf_smc_set_tcp_option_cond,
> +};

These stubs don't inspire confidence that smc_ops api
will be sufficient.
Please implement a real bpf prog that demonstrates the actual use case.

See how bpf_cubic was done. On the day one it was implemented
as a parity to builtin cubic cong control.
And over years we didn't need to touch tcp_congestion_ops.
To be fair that api was already solid due to in-kernel cc modules,
but bpf comes with its own limitations, so it wasn't a guarantee
that tcp_congestion_ops would be enough.
Here you're proposing a brand new smc_ops api while bpf progs
are nothing but stubs. That's not sufficient to prove that api
is viable long term.

In terms of look and feel the smc_ops look ok.
The change from v1 to v2 was a good step.

pw-bot: cr