Re: [dpdk-dev] [EXT] Re: [PATCH v2 1/4] eal: add API to check if its interrupt context

[Harman Kalra <hkalra@marvell.com>]

On Wed, Nov 27, 2019 at 04:03:19PM -0800, Stephen Hemminger wrote:
> External Email
> 
> ----------------------------------------------------------------------
> On Wed, 27 Nov 2019 15:52:19 +0530
> Sunil Kumar Kori <skori@marvell.com> wrote:
> 
> >  
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice
> > + *
> > + * Check if currently executing in interrupt context
> > + *
> > + * @return
> > + *  - positive in case of interrupt context
> > + *  - zero in case of process context
> > + *  - negative if unsuccessful
> > + */
> > +__rte_experimental
> > +int
> > +rte_thread_is_intr(void);
> 
> If you only need this in drivers, it should be internal not exposed
> as part of API

Sorry, but can you please help me understand the query. Do you mean:
* Since "rte_thread_is_intr"  would be used only used by
libraries/drivers and not by any external application, rather having
it in "rte_interrupt.h", we should have it in some internal header
file like "eal_private.h" ??

ANS - Yes we can do that but since all other related APIs like
"rte_intr_ack", "rte_intr_enable/disable" which are also used by
drivers/lib and not application, are prototyped in "rte_interupt.h".

OR do u mean
* Since only octeontx2 driver is using this, why it is exposed as an API
rather it should be defined as some driver internal function ??

ANS - "rte_thread_is_intr" is an counter part of "in_interrupt()" in
DPDK, which will return whether the current execution is in interrupt
context. This helps in dealing with nested interrupts case. We faced a
similar case while handling hotplug probing initiated via secondary
process.
We believe this API could be very useful for many drivers which might
end up in handling nested interrupts case.

Thanks
Harman