linux-kernel - Re: [PATCH RFC net-next v2] page_pool: import Jesper's page

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: <aEiWhUDsFskkcv46@x1>
Date: Tue, 10 Jun 2025 17:33:09 -0300
From: Arnaldo Carvalho de Melo <acme@...nel.org>
To: Ilias Apalodimas <ilias.apalodimas@...aro.org>
Cc: Jesper Dangaard Brouer <hawk@...nel.org>,
	Mina Almasry <almasrymina@...gle.com>,
	Toke Høiland-Jørgensen <toke@...hat.com>,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-kselftest@...r.kernel.org,
	"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>, Shuah Khan <shuah@...nel.org>
Subject: Re: [PATCH RFC net-next v2] page_pool: import Jesper's page_pool
 benchmark

On Tue, Jun 10, 2025 at 10:41:49AM +0300, Ilias Apalodimas wrote:
> On Wed, 4 Jun 2025 at 11:39, Jesper Dangaard Brouer <hawk@...nel.org> wrote:
> > Okay, I think Ilias'es comment[1] and ACK convinced me, let us merge
> > this as-is.  We have been asking people to run it over several years
> > before accepting patches. We shouldn't be pointing people to use
> > out-of-tree tests for accepting patches.

> > It is not perfect, but it have served us well for benchmarking in the
> > last approx 10 years (5 years for page_pool test).  It is isolated as a
> > selftest under (tools/testing/selftests/net/bench/page_pool/).

> > Realistically we are all too busy inventing a new "perfect" benchmark
> > for page_pool. That said, I do encourage others with free cycles to
> > integrated a better benchmark test into `perf bench`.  Then we can just
> > remove this module again.

> I'll spend some time looking at acme comments. They seem to be moving
> towards the right direction

Glad that you think that way, and to add another perspective, 'perf
test' and 'perf bench' goals are to run in any kernel, not just some
specific one where a regression was fixed, so people running plain 'perf
bench' will run whatever tests we add and thus widen the tester base for
the benchmarks in there.

Being able to combine 'perf trace perf bench', 'perf stat perf bench',
etc is something common and powerful.

But then the most important thing is to have actionable and expertly
written benchmarks in place, that have been in use for a long time, in
whatever form :-)

- Arnaldo