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

[Stephen Hemminger <stephen@networkplumber.org>]

On Thu, 28 Nov 2019 08:10:23 +0000
Harman Kalra <hkalra@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 <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

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.