From: Ratheesh Kannoth <rkannoth@marvell.com>
Date: Thu, 3 Aug 2023 02:08:18 +0000
quoted
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
quoted
+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