netdev - Re: [PATCH net-next 08/11] iavf: switch to Page Pool

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]

Date: Wed, 31 May 2023 13:18:59 -0700
From: David Christensen <drc@...ux.vnet.ibm.com>
To: Alexander Lobakin <aleksander.lobakin@...el.com>
Cc: "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Maciej Fijalkowski <maciej.fijalkowski@...el.com>,
        Magnus Karlsson <magnus.karlsson@...el.com>,
        Michal Kubiak <michal.kubiak@...el.com>,
        Larysa Zaremba <larysa.zaremba@...el.com>,
        Jesper Dangaard Brouer <hawk@...nel.org>,
        Ilias Apalodimas <ilias.apalodimas@...aro.org>,
        Christoph Hellwig <hch@....de>, netdev@...r.kernel.org,
        intel-wired-lan@...ts.osuosl.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 08/11] iavf: switch to Page Pool



On 5/25/23 4:08 AM, Alexander Lobakin wrote:
>> Any plans to add page pool fragmentation support (i.e.
>> PP_FLAG_PAGE_FRAG) in the future to better support architectures with
>> larger page sizes such as 64KB on ppc64le?
> 
> Currently no, we resigned from page fragmentation due to the complexity
> and restrictions it provides for no benefits on x86_64. But I remember
> that pages > 4 Kb exist (I have a couple MIPS boards where I have fun
> sometimes and page size is set to 16 Kb there. But still always use 1
> page per frame).
> By "better support" you mean reducing memory usage or something else?

Yes, reducing memory waste.  Current generation P10 systems default to 
quad-port, 10Gb copper i40e NICs.  When you combine a large number of 
CPUs, and therefore a large number of RX queues, with a 64KB page 
allocation per packet, memory usage can balloon very quickly as you add 
additional ports.

Would you be open to patches to address this further down the road as 
your refactoring effort gets closer to completion?

Dave