> > > -----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.
Ok, I understand all that, but what you suggest then - not use rte_malloc()
anywhere
In DPDK code, even when it is a hot-path?
