Messages in this thread | | | Date | Thu, 3 Aug 2023 17:07:07 +0200 | Subject | Re: [PATCH net] octeontx2-pf: Set maximum queue size to 16K | From | Alexander Lobakin <> |
| |
From: Ratheesh Kannoth <rkannoth@marvell.com> Date: Thu, 3 Aug 2023 02:08:18 +0000
>> From: Alexander Lobakin <aleksander.lobakin@intel.com> >> Sent: Wednesday, August 2, 2023 9:42 PM >> To: Ratheesh Kannoth <rkannoth@marvell.com> >> Subject: [EXT] Re: [PATCH net] octeontx2-pf: Set maximum queue size to 16K > >> +ring->rx_max_pending = 16384; /* Page pool support on RX */ >> >> This is very hardcodish. Why not limit the Page Pool size when creating >> instead? It's perfectly fine to have a queue with 64k descriptors and a Page >> Pool with only ("only" :D) 16k elements. >> Page Pool size affects only the size of the embedded ptr_ring, which is used >> for indirect (locking) recycling. I would even recommend to not go past 2k for >> PP sizes, it makes no sense and only consumes memory. > > 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. If you prove with some performance numbers that creating page_pools with the ptr_ring size of 2k when the rings have 32k descriptors really hurt the throughput comparing to 16k PP + 32k rings, I'll change my mind.
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.
Thanks, Olek
| |