13/10/2021 20:52, Thomas Monjalon:
> 13/10/2021 19:57, Harman Kalra:
> > From: dev <dev-boun...@dpdk.org> On Behalf Of Harman Kalra
> > > From: Thomas Monjalon <tho...@monjalon.net>
> > > > 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.
[...]
> > > > 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.
[...]
> > > There are couple of more dependencies on glibc heap APIs:
> > > 1. "rte_eal_alarm_init()" allocates an interrupt instance which is used
> > > for
> > > timerfd, is called before "rte_eal_memory_init()" which does the memseg
> > > init.
> > > Not sure what all challenges we may face in moving alarm_init after
> > > memory_init as it might break some subsystem inits.
> > > Other option could be to allocate interrupt instance for timerfd on first
> > > alarm_setup call.
>
> Indeed it is an issue.
>
> [...]
>
> > > There are many other drivers which statically declares the interrupt
> > > handles
> > > inside their respective private structures and memory for those structure
> > > was allocated from heap. For such drivers I allocated interrupt instances
> > > also
> > > using glibc heap APIs.
>
> Could you use rte_malloc in these drivers?
If we take the direction of 2 different allocations mode for the interrupts,
I suggest we make it automatic without any API parameter.
We don't have any function to check rte_malloc readiness I think.
But we can detect whether shared memory is ready with this check:
rte_eal_get_configuration()->mem_config->magic == RTE_MAGIC
This check is true at the end of rte_eal_init, so it is false during probing.
Would it be enough? Or should we implement rte_malloc_is_ready()?
