04/10/2021 11:57, David Marchand:
> On Mon, Oct 4, 2021 at 10:51 AM Harman Kalra <hka...@marvell.com> wrote:
> > > > +struct rte_intr_handle *rte_intr_handle_instance_alloc(int size,
> > > > + bool
> > > > +from_hugepage) {
> > > > + struct rte_intr_handle *intr_handle;
> > > > + int i;
> > > > +
> > > > + if (from_hugepage)
> > > > + intr_handle = rte_zmalloc(NULL,
> > > > + size * sizeof(struct
> > > > rte_intr_handle),
> > > > + 0);
> > > > + else
> > > > + intr_handle = calloc(1, size * sizeof(struct
> > > > + rte_intr_handle));
> > >
> > > We can call DPDK allocator in all cases.
> > > That would avoid headaches on why multiprocess does not work in some
> > > rarely tested cases.
> > > Wdyt?
> > >
> > > Plus "from_hugepage" is misleading, you could be in --no-huge mode,
> > > rte_zmalloc still works.
> >
> > <HK> In mellanox 5 driver interrupt handle instance is freed in destructor
> > " mlx5_pmd_interrupt_handler_uninstall()" while DPDK memory allocators
> > are already cleaned up in "rte_eal_cleanup". Hence I allocated interrupt
> > instances for such cases from normal heap. There could be other such cases
> > so I think its ok to keep this support.
>
> This is surprising.
> Why would the mlx5 driver wait to release in a destructor?
> It should be done once no interrupt handler is necessary (like when
> stopping all ports), and that would be before rte_eal_cleanup().
I agree with David.
I prefer a simpler API which always use rte_malloc,
and make sure interrupts are always handled between
rte_eal_init and rte_eal_cleanup.
The mlx5 PMD could be reworked to match this requirement.
In any case we should not any memory management in constructors/destructors.
