linux-kernel - RE: [EXT] Re: [PATCH net] octeontx2-pf: Set maximum queue size to 16K

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: <MWHPR1801MB1918C41E2A44527D178F213CD309A@MWHPR1801MB1918.namprd18.prod.outlook.com>
Date:   Fri, 4 Aug 2023 02:25:55 +0000
From:   Ratheesh Kannoth <rkannoth@...vell.com>
To:     Alexander Lobakin <aleksander.lobakin@...el.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Sunil Kovvuri Goutham <sgoutham@...vell.com>,
        Geethasowjanya Akula <gakula@...vell.com>,
        Subbaraya Sundeep Bhatta <sbhatta@...vell.com>,
        Hariprasad Kelam <hkelam@...vell.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "pabeni@...hat.com" <pabeni@...hat.com>
Subject: RE: [EXT] Re: [PATCH net] octeontx2-pf: Set maximum queue size to 16K

> From: Alexander Lobakin <aleksander.lobakin@...el.com>
> Sent: Thursday, August 3, 2023 8:37 PM
> To: Ratheesh Kannoth <rkannoth@...vell.com>
> Subject: [EXT] Re: [PATCH net] octeontx2-pf: Set maximum queue size to 16K


> > These recycling will impact on performance, right ? else, why didn't page
> pool made this size as constant.
> 
> Page Pool doesn't need huge ptr_ring sizes to successfully recycle pages.
> Especially given that the recent PP optimizations made locking recycling
> happen much more rarely.
Got it. Thanks. 

> Re "size as constant" -- because lots of NICs don't need more than 256 or 512
> descriptors and it would be only a waste to create page_pools with huge
> ptr_rings for them. Queue sizes bigger than 1024 (ok, maybe
> 2048) is the moment when the linear scale stops working. That's why I
> believe that going out of [64, 2048] for page_pools doesn't make much
> sense.
So, will clamp to 2048 in page_pool_init() ? But it looks odd to me, as 
User requests > 2048,  but will never be aware that it is clamped to 2048.
Better do this clamping in Driver and print a warning  message ? 

-Ratheesh