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] [thread-next>] [day] [month] [year] [list]

Message-ID: <87h615m6cp.fsf@toke.dk>
Date: Wed, 28 May 2025 11:28:54 +0200
From: Toke Høiland-Jørgensen <toke@...hat.com>
To: Mina Almasry <almasrymina@...gle.com>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-kselftest@...r.kernel.org, Jesper Dangaard Brouer <hawk@...nel.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>, Ilias Apalodimas <ilias.apalodimas@...aro.org>,
 Arnaldo Carvalho de Melo <acme@...nel.org>
Subject: Re: [PATCH RFC net-next v2] page_pool: import Jesper's page_pool
 benchmark

Mina Almasry <almasrymina@...gle.com> writes:

> On Mon, May 26, 2025 at 5:51 AM Toke Høiland-Jørgensen <toke@...hat.com> wrote:
>> > Fast path results:
>> > no-softirq-page_pool01 Per elem: 11 cycles(tsc) 4.368 ns
>> >
>> > ptr_ring results:
>> > no-softirq-page_pool02 Per elem: 527 cycles(tsc) 195.187 ns
>> >
>> > slow path results:
>> > no-softirq-page_pool03 Per elem: 549 cycles(tsc) 203.466 ns
>> > ```
>> >
>> > Cc: Jesper Dangaard Brouer <hawk@...nel.org>
>> > Cc: Ilias Apalodimas <ilias.apalodimas@...aro.org>
>> > Cc: Jakub Kicinski <kuba@...nel.org>
>> > Cc: Toke Høiland-Jørgensen <toke@...e.dk>
>> >
>> > Signed-off-by: Mina Almasry <almasrymina@...gle.com>
>>
>> Back when you posted the first RFC, Jesper and I chatted about ways to
>> avoid the ugly "load module and read the output from dmesg" interface to
>> the test.
>>
>
> I agree the existing interface is ugly.
>
>> One idea we came up with was to make the module include only the "inner"
>> functions for the benchmark, and expose those to BPF as kfuncs. Then the
>> test runner can be a BPF program that runs the tests, collects the data
>> and passes it to userspace via maps or a ringbuffer or something. That's
>> a nicer and more customisable interface than the printk output. And if
>> they're small enough, maybe we could even include the functions into the
>> page_pool code itself, instead of in a separate benchmark module?
>>
>> WDYT of that idea? :)
>
> ...but this sounds like an enormous amount of effort, for something
> that is a bit ugly but isn't THAT bad. Especially for me, I'm not that
> much of an expert that I know how to implement what you're referring
> to off the top of my head. I normally am open to spending time but
> this is not that high on my todolist and I have limited bandwidth to
> resolve this :(
>
> I also feel that this is something that could be improved post merge.
> I think it's very beneficial to have this merged in some form that can
> be improved later. Byungchul is making a lot of changes to these mm
> things and it would be nice to have an easy way to run the benchmark
> in tree and maybe even get automated results from nipa. If we could
> agree on mvp that is appropriate to merge without too much scope creep
> that would be ideal from my side at least.

Right, fair. I guess we can merge it as-is, and then investigate whether
we can move it to BPF-based (or maybe 'perf bench' - Cc acme) later :)

-Toke