On 20/02/2025 17:45, Stephen Hemminger wrote:
On Thu, 20 Feb 2025 16:39:52 +0000
Konstantin Ananyev <[email protected]> wrote:
-----Original Message-----
From: Stephen Hemminger <[email protected]>
Sent: Thursday, February 20, 2025 4:12 PM
To: lihuisong (C) <[email protected]>
Cc: [email protected]; [email protected]; [email protected];
[email protected]; [email protected];
liuyonglong <[email protected]>
Subject: Re: [PATCH] power: use hugepage memory for queue list entry structure
On Thu, 20 Feb 2025 17:01:53 +0800
"lihuisong (C)" <[email protected]> wrote:
The queue_list_entry structure data is used in rx_callback of io path
when enable PMD Power Management. However its memory is currently from
normal heap memory. For better performance, use hugepage memory to
replace it.
Signed-off-by: Huisong Li <[email protected]>
How is that in a hot path where this could matter?
AFAIU - it is used in RX/TX callbacks that power library installs,
so I presume will get hit on every eth_rx_burst/tx_burst calls.
The safety rails in rte_malloc() are much less than regular malloc().
I prefer some degree of safety from checkers and malloc library internals.
Didn't get your point - what's suddenly wrong with rte_malloc()?
Coverity and Gcc analyzer treat malloc as special case.
With attributes rte_malloc gets similar treatment but not quite as much.
Also internally, malloc and free have more heap pool sanity checks.
In name of performance, those don't exist in rte_malloc().
Lastly hugepages are limited resource, so they should only be used when needed.
The last thing I would associate with rte_malloc is performance. I'm not
sure I follow - which "sanity checks" were omitted from rte_malloc "in
the name of performance" that are present in regular malloc?
--
Thanks,
Anatoly
