Mina Almasry <almasrym...@google.com> writes: > On Mon, May 26, 2025 at 5:51 AM Toke Høiland-Jørgensen <t...@redhat.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 <h...@kernel.org> >> > Cc: Ilias Apalodimas <ilias.apalodi...@linaro.org> >> > Cc: Jakub Kicinski <k...@kernel.org> >> > Cc: Toke Høiland-Jørgensen <t...@toke.dk> >> > >> > Signed-off-by: Mina Almasry <almasrym...@google.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
