netdev - Re: [PATCH bpf-next v1 0/3] bpf, sockmap: Improve performance with CPU affinity

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAADnVQJWx9NJPGSrTv=WAwp9Zf8eHGNFwpC5BX5CYjMWBcWoAA@mail.gmail.com>
Date: Tue, 29 Apr 2025 16:53:04 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Jiayuan Chen <jiayuan.chen@...ux.dev>
Cc: bpf <bpf@...r.kernel.org>, Jiayuan Chen <mrpre@....com>, 
	Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, 
	Andrii Nakryiko <andrii@...nel.org>, Martin KaFai Lau <martin.lau@...ux.dev>, 
	Eduard Zingerman <eddyz87@...il.com>, Song Liu <song@...nel.org>, 
	Yonghong Song <yonghong.song@...ux.dev>, John Fastabend <john.fastabend@...il.com>, 
	KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>, 
	Jiri Olsa <jolsa@...nel.org>, Jonathan Corbet <corbet@....net>, Jakub Sitnicki <jakub@...udflare.com>, 
	"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>, 
	Kuniyuki Iwashima <kuniyu@...zon.com>, Willem de Bruijn <willemb@...gle.com>, Mykola Lysenko <mykolal@...com>, 
	Shuah Khan <shuah@...nel.org>, Jiapeng Chong <jiapeng.chong@...ux.alibaba.com>, 
	"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, 
	Network Development <netdev@...r.kernel.org>, 
	"open list:KERNEL SELFTEST FRAMEWORK" <linux-kselftest@...r.kernel.org>
Subject: Re: [PATCH bpf-next v1 0/3] bpf, sockmap: Improve performance with
 CPU affinity

On Tue, Apr 29, 2025 at 4:47 PM Jiayuan Chen <jiayuan.chen@...ux.dev> wrote:
>
> >
> > This looks to me like an artificial benchmark.
> > Surely perf will be higher when wq is executed on free cpu.
> > In production all cpus likely have work to do, so this whole
> > approach 'lets ask wq to run on that cpu' isn't going to work.
> > Looks like RPS helps. Use that. I think it will scale and work
> > better when the whole server is loaded.
> > pw-bot: cr
> >
>
> Hi Alexei, you're right for requests coming from a remote host, all CPUs
> are running; in cloud-native scenarios where Sidecars are widely used,
> they access each other through loopback, but for requests accessing each
> other through loopback, the wq (workqueue) will definitely run on the CPU
> where the client is located (based on the implementation of loopback and wq).
> Since the Sidecar itself is bound to a CPU, which means that in actual
> scenarios, the CPU bound to the gateway (reverse proxy) program using sockmap
> cannot be fully utilized.
>
> Enabling RPS can alleviate the sockmap issue, but it will introduce an extra
> software calculation, so from a performance perspective, we still expect to
> have a solution that can achieve the highest performance.

And I think it's wrong to optimize for performance of one particular setup.
An API that picks a cpu is difficult to get right.
Too easy to make performance worse.