On Thu, Nov 28, 2019 at 08:45:42AM -0800, Stephen Hemminger wrote: > On Thu, 28 Nov 2019 08:10:23 +0000 > Harman Kalra <hka...@marvell.com> wrote: > > > 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 > > What I meant was that some functions in EAL are documented as > being internal (flagged with @internal) and don't show up in > the documented API. > > My concern is that if we make this part of the public API, it makes > it harder to change structural things like the interrupt thread > later. The interrupt thread is already problematic for several > other usages. >
I think now I understood your point, I will move prototype of this API to "common/include/rte_eal_interrupts.h", flag it as @internal and resend next version. I think this file was created for such APIs only as its description says. /** * @file rte_eal_interrupts.h * @internal * * Contains function prototypes exposed by the EAL for interrupt handling by * drivers and other DPDK internal consumers. */ Thanks Harman
