netdev - Re: [RFC net-next 1/2] page_pool: allow caching from safely localized NAPI

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: <3da1da0972c6c6af1fd4db2e4227043fab78e37f.camel@nvidia.com>
Date:   Wed, 5 Apr 2023 17:04:43 +0000
From:   Dragos Tatulea <dtatulea@...dia.com>
To:     "kuba@...nel.org" <kuba@...nel.org>
CC:     "hawk@...nel.org" <hawk@...nel.org>,
        Tariq Toukan <tariqt@...dia.com>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "ilias.apalodimas@...aro.org" <ilias.apalodimas@...aro.org>
Subject: Re: [RFC net-next 1/2] page_pool: allow caching from safely localized
 NAPI

On Mon, 2023-04-03 at 10:12 -0700, Jakub Kicinski wrote:
> On Mon, 3 Apr 2023 18:30:55 +0300 Ilias Apalodimas wrote:
> > > Meaning in page_pool_return_skb_page() or all the way from
> > > napi_consume_skb()? The former does indeed sounds like a good
> > > idea!  
> > 
> > page_pool_return_skb_page() (and maybe page_pool_put_full_page()).
> > FWIW we completely agree on napi_consume_skb().  We are trying to
> > keep
> > page_pool and the net layer as disjoint as possible.  The only
> > point
> > we 'pollute' networking code is the recycle bit checking and we'd
> > prefer keeping it like that
> 
> Ack, OTOH plumbing thru the budget argument within netdev code should
> not be a major refactoring. So maybe I should do that after all.
> 
> Otherwise we have two different conditions - netdev only recycles
> skbs
> based on the NAPI budget != 0, but page pool will assume that
> in_softirq() && !in_hardirq() is always safe.
> 
> The latter is safe, I think, unless someone adds a print half way
> thru
> the cache update... but then it's also safe in NAPI skb recycling,
> so napi_consume_skb() should stop taking the budget and just look
> at preempt flags...
> 
> To make the correctness obvious, for now, I think I will refactor 
> the netdev code to pass a "in NAPI poll" bool to
> page_pool_return_skb_page(), and add a WARN_ON(!softirq || hardirq).
> 
> Let's see how the code ends up looking, I'll send it as RFCv2 rather
> than PATCH to make it clear I'm not sure it's okay with you :)

Wow, thanks for picking this up so fast!

After enabling this in the mlx5 driver, there is already improved
page_pool cache usage for our test with the application running on the
same CPU with the receive queue NAPI (0 -> 98 % cache usage).

Looking forward to the v2.