linux-kernel - Re: [PATCH RFC net-next v1] 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: <20250325153854.4e3b6834@kernel.org>
Date: Tue, 25 Mar 2025 15:38:54 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Mina Almasry <almasrymina@...gle.com>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org, Jesper Dangaard
 Brouer <hawk@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>, Ilias
 Apalodimas <ilias.apalodimas@...aro.org>, Toke Høiland-Jørgensen <toke@...e.dk>
Subject: Re: [PATCH RFC net-next v1] page_pool: import Jesper's page_pool
 benchmark

On Mon, 24 Mar 2025 13:21:53 -0700 Mina Almasry wrote:
> > Why not in tools/testing? I thought selftest infra supported modules.  
> 
> You must be referring to TEST_GEN_MODS_DIR? Yes, that seems better. We
> don't use it in tools/testing/selftests/net but it is used in
> tool/testing/selftests/mm and page_frag_test.ko is a very similar
> example. I can put it in tools/testing/selftests/net/page_pool_bench
> or something like that.
> 
> Also I guess you're alluding that this benchmark should be a selftest
> as well, right? I can make it a selftest but probably for starters the
> test will run and output the perf data but will exit code 4 to skip,
> right? I'm not sure it is consistent enough to get pass/fail data from
> it. When I run it in my env it's mostly consistent but i'm not sure
> across evironments.

skip in KTAP is just pass + annotation.
I think we should be reporting pass + result.
I don't think a format for that has been chosen, so we can just pick
our own? :) We already use our own annotations like "# time=450ms"

Maybe report a "test case" for every datapoint we may want to track
and add "# perf=Xu" annotation, where X is the numeric result and u is
a unit (with an optional metric prefix)?