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. -- Thanks, Mina
