Re: [PATCH RFC net-next v1] page_pool: import Jesper's page_pool benchmark

[Jesper Dangaard Brouer]

On 24/03/2025 21.23, Mina Almasry wrote:
> On Mon, Mar 10, 2025 at 2:15 AM Toke Høiland-Jørgensen <toke@xxxxxxx> wrote:
> > Mina Almasry <almasrymina@xxxxxxxxxx> writes:
> >
> > > From: Jesper Dangaard Brouer <hawk@xxxxxxxxxx>
> > >
> > > We frequently consult with Jesper's out-of-tree page_pool benchmark to
> > > evaluate page_pool changes.
> > >
> > > Consider importing the benchmark into the upstream linux kernel tree so
> > > that (a) we're all running the same version, (b) pave the way for shared
> > > improvements, and (c) maybe one day integrate it with nipa, if possible.
> > >
> > > I imported the bench_page_pool_simple from commit 35b1716d0c30 ("Add
> > > page_bench06_walk_all"), from this repository:
> > > https://github.com/netoptimizer/prototype-kernel.git
> > >
> > > I imported the benchmark, largely as-is. I only fixed build or
> > > checkpatch issues.
> > >
> > > Cc: Jesper Dangaard Brouer <hawk@xxxxxxxxxx>
> > > Cc: Ilias Apalodimas <ilias.apalodimas@xxxxxxxxxx>
> > > Cc: Jakub Kicinski <kuba@xxxxxxxxxx>
> > > Cc: Toke Høiland-Jørgensen <toke@xxxxxxx>
> > > Cc: netdev@xxxxxxxxxxxxxxx
> > > Signed-off-by: Mina Almasry <almasrymina@xxxxxxxxxx>
> > >
> > > ---
> > >
> > > RFC discussion points:
> > > - Desirable to import it?
> >
> > I think so, yeah.
> >
> > > - Can the benchmark be imported as-is for an initial version? Or needs
> > >    lots of modifications?
> >
> > One thing that I was discussing with Jesper the other day is that the
> > current version allocates the page_pool itself in softirq context, which
> > leads to some "may sleep" warning. I think we should fix that before
> > upstreaming.
>
> I don't think I saw that warning for whatever reason. Do you by any
> chance have a fix that I can squash? Or do you think it is very
> critical to fix this before upstreaming? I.e. not follow up with a
> fix?

The tasklet trick in the benchmark module is to fake that code is
running in softirq context, which avoids taking the _bh lock variants.

In the past the performance was really different between the two
execution contexts, but in all of my recent experiments [1][2], the
performance differences are gone. So, I think we can simply drop the
ugly tasklet setup tricks.

 [1] 
https://github.com/xdp-project/xdp-project/blob/main/areas/mem/page_pool07_bench_DMA_fix.org
 [2] 
https://github.com/xdp-project/xdp-project/blob/main/areas/mem/page_pool08_bench_AMD.org

BTW it is awesome that you are pushing this to get upstreamed.

--Jesper