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 <sk...@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
